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PREFACE 


This  Technical  Report  presents  the  results  of  work  performed  by  the  Boeing 
Military  Airplane  Company,  Seattle,  Washingtor,  under  Air  Force  Contract 
F33615-80-C-2004,  during  the  period  from  September  1980  through  March  1983. 
The  work  is  sponsored  by  the  Aero  Propulsion  Laboratory,  Air  Force  Wright 
Aeronautical  Laboratories,  Wright-Patterson  Air  Force  Base,  Ohio,  under 
Project  3145,  Task  314529,  Work  Unit  31452959  with  Mr.  Duane  G.  Fox, 
AFWAL/P00S-2 ,  as  project  engineer. 


The  Harris  Corporation,  Melbourne,  fori  da  and  the  Eaton  Corporation, 
Milwaukee,  Wisconsin  were  subcontracted  to  provide  information  and 
consultation  in  the  areas  of  multiplex  data  bus  equipment  and  solid  state 
power  controllers. 


This  report  covers  Phase  I  and  Phase  II  of  a  two  Dhase  program  to  design  an 
advanced  aircraft  electrical  system.  Phase  I  cove-ed  a  preliminary  design  of 
the  electrical  system.  This  included  a  requirements  analysis  and  an 
evaluation  of  concepts  applicable  to  the  system  design.  Phase  II  covered  the 
detailed  design  of  the  advanced  aircraft  electrical  system  and  laboratory 
supoort  hardware  to  demonstrate  the  system  in  the  laboratory.  In  addition, 
task  ?  of  Phase  II  covers  the  conceptual  design  of  a  multiple  data  bus 
jrchitecture  for  the  advanced  aircraft  electrical  system. 


The  program  manager  was  I.  S.  Mehdi.  The  report  was  prepared  by  T.  R.  Boldt, 
G.  L.  Dunn,  D.  E.  Hankins,  and  P.  J.  Leong  who  were  technically  responsible 
for  the  work. 
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SUMMARY 


In  this  study,  advanced  concepts  pertaining  to  electrical  systems  were 
investigated.  These  concepts  were  then  applied  to  the  design  of  an  advanced 
aircraft  electrical  system  (AAES).  As  part  of  this  study,  a  laboratory 
demonstrator  for  the  AAES  was  also  designed.  The  AAES  is  designed  to  meet  the 
requirements  for  a  1990  time  frame  two-engine  tactical  aircraft  with 
multimission  capability.  The  system  performs  the  following  major  functions  on 
the  aircraft. 

o  Provide  electrical  power  to  meet  all  mission  requirements 
o  Distribute  electrical  power  to  the  loads 
o  Provide  electrical  system  protection 

o  Control  the  distribution  of  electrical  power  and  provide  load  management 

Electrical  power  generation  consists  of  those  functions  necessary  to  assure 
that  proper  quality  power  is  provided  for  distribution.  Distribution  of 
electrical  power  relates  to  the  electrical  bus  structure,  AC  and  DC,  along 
with  reliability  and  redundancy  considerations  to  ensure  that  v.i:e  generated 
electrical  power  is  optimally  delivered  to  the  loads.  Electrical  system 
protection  involves  the  automatic  detection  and  isolation  of  system  faults 
such  as  shore  circuits  and  generator  failures.  Finally,  control  of  power 
distribution  encompasses  the  on/off  control  o*  mfvidual  1oads,  load  shedding 
and  load  sequencing. 

The  key  characteristics  of  the  AAES  are: 

o  Integrated  avionics  and  power  data  bus  configuration  consisting  of  Digital 
Avionics  Information  System  (DAIS)  standard  elements  (MIL-STD-1750 
processor,  MIL-STD-1553B  data  bus,  controls  and  displays,  and  remote 
terminals  RT). 

o  Intelligent  Electrical  Load  Management  Centers  (ELMC)  capable  of 
controlling  power  to  loads. 

o  Built-in-test  (BIT)  capability  to  isolate  faults  to  the  module  level.  BIT 
includes  both  circuit  and  data  monitoring  checks. 


xii 


Solid  State  P  ow6r  Con ^rollers  (SSPC  )  to  replace  circuit  breakers  and  power 
control  switches.  SSPCs  are  turned  on/off  via  computer  control. 


Generator  control,  protection  and  status  monitoring  by  a  Generator  Control 
Unit  (GCU)  compatible  with  DAIS  hardware  and  software. 


Multi mission  data  information  system  through  programmable  system 
processors,  ELMCs  and  standard  DAIS  elements. 


Automatic  load  management  for  increased  aircraft  survivability  and 
probability  of  mission  completion. 


SECTION  I 


INTRODUCTION 

1.  BACKGROUND 

/ 

The  Air  Force  Wright  Aeronautical  Laboratories  (AFWAL)  Aero  Propulsion 
Laboratory  has  been  sponsoring  research  and  development  programs  directed 
toward  applying  advanced  solid  state  power  switching  and  computer  control 
technology  to  aircraft  electrical  power  systems.  Development  of  components 
and  subsystems  utilizing  solid  state  power  switching  and  microprocessor-based 
computer  technology  has  progressed  rapidly.  Multiplexing  technigues  have  been 
developed  for  transmission  and  processing  of  electrical  system  control  data. 
This  data  usually  consists  of  a  large  number  of  discrete  (on/off)  signals  and 
information  for  solving  control  logic  equations.  Multiplex  hardware  and 
software  designs  have  been  optimized  for  electrical  system  control 
applications  such  as  the  B-l  E-Mux  system.  This,  however,  results  in  high 
initial  development,  integration  and  logistics  costs.  On  large  aircraft  the 
amount  of  signal  processing  and  data  transfer  may  justify  the  use  of  a 
separate  and  optimized  multiplex  system  for  electrical  system  control; 
however,  in  the  case  of  smaller  aircraft  this  may  not  be  the  most  cost 
effective  solution. 

For  small  aircraft,  where  the  electrical  system  signal  processing  and  data 
transfer  may  not  be  as  large  as  for  the  B-l,  it  may  be  possible  to  integrate 
electrical  system  control  with  the  avionics  system  in  a  single  data  bus  system 
as  developed  in  the  Digital  Avionics  Information  System  (DAIS)  program. 
Previous  studies,  such  as  AFAPL-TR-73-41  (Reference  1),  examined  this  concept 
and  concluded  that  integration  was  possible.  Integration  of  the  electrical 
power  control  was  also  examined  in  the  DAIS  program  but  wac  not  implemented. 
Areas  of  concern  with  such  integration  are  that  the  electrical  power  control 
was  also  examined  in  the  DAIS  program  but  was  not  implemented.  Areas  of 
concern  with  such  integration  are  that  the  electrical  power  redundancy 
required  for  mission  essential  functions  may  not  be  adequate  for  flight 
critical  functions.  Another  area  of  concern  is  that  if  the  electrical  power 
system  is  controlled  by  the  multiplex  system  and  in  turn  the  multiplex  system 
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requires  electrical  power  to  operate,  procedures  must  be  devised  to  power-up 
the  system.  The  third  area  of  concern  is  that  growth  of  the  data  bus  traffic 
may  reach  the  point  where  system  complexity  would  negate  the  technical  and 
cost  advantages  of  an  integrated  system. 

In  order  to  permit  evaluation  of  aircraft  electrical  power  system  design, 
laboratory  simulators  need  to  be  designed  and  built.  An  A-7  electrical  system 
simulator  (Reference  2)  was  built  by  the  Aero  Propulsion  Laboratory  for 
demonstrating  functional  operation  of  the  solid  state  distribution  concept  and 
to  show  that  electromagnetic  interference  (EMI)  presented  no  problem. 

Therefore  this  simulator  was  built  so  that  it  would  have  the  same  ground 
planes  and  shielding  that  exists  on  the  A-7  aircraft.  This  type  of  simulator 
has  several  disadvantages  such  as,  difficulty  in  maintenance  due  to  tight 
hardware  locations,  difficulty  in  making  changes  to  the  wiring  harness,  and 
poor  utilization  of  laboratory  floor  space. 

Modular  concepts  of  building  a  laboratory  simulator  (Reference  3)  provide  the 
advantages  of  lower  cost  easy  modification  and  more  universal  application, 
even  though  they  do  not  allow  for  adequate  EMI  evaluation.  To  date  no 
simulator  has  been  developed  to  evaluate  integrated  power  and  avionics  data 
bus  control  concepts. 

2.  PROGRAM  OBJECTIVES 

The  overall  objective  of  this  contract  was  to  develop  an  aircraft  electrical 
power  distribution  and  control  system  that  is  integrated  to  the  fullest 
practical  extent  with  an  aircraft  digital  avionics  information  management 
system.  Specifically  this  program  had  two  distinct  objectives.  They  we^e, 
first  to  define  the  requirements  and  conduct  the  design  of  a  computer 
controlled,  solid  state  electrical  power  distribution  and  control  system  for  a 
small  two  engine  tactical  aircraft,  and  second  to  develop  the  design  of  a 
laboratory  simulator  for  evaluation  of  the  aircraft  electrical  system. 

3.  APPROACH 

To  achieve  the  objectives  of  this  program,  a  two  phase  study  with  three  tasks 
in  Phase  I  and  three  tasks  in  Phase  II  was  undertaken.  The  tasks  for  each 
Phase  were  as  follows: 
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Phase  I  Analysis  and  Preliminary  Design 
Task  1  Requirements  Analysis 

Task  2  Conceptual  Design 

Task  3  Preliminary  Design 

Phase  II  Detailed  Design 

Task  1  System  Hardware  and  Software  Development 
Task  2  Support  Hardware  and  Software  Development 

Task  3  Multiple  Data  Bus  Architecure  Investigations 

The  program  flow  chart  for  Phase  I  is  shewn  in  Figure  1.  During  Task  1  the 
requirements  were  defined  for  the  electrical  power  system  and  the  integrated 
power  system  control  for  a  small  two  engine  tactical  aircraft  which  will  be 
capable  of  performing  various  missions  (fighter,  attack,  reconnaissance, 
trainer,  electronic  warfare,  fighter  bomber).  In  addition,  a  data  base  of 
information  regarding  subsystems  and  component  hardware  and  software  of  an 
Advanced  Electrical  Power  Systems  (AEPS)  simulator  was  accumulated.  The 
requirements  definition  and  data  base  were  developed  with  the  primary 
objective  of  achieving  the  most  cost  effective  designs  for  both  the  aircraft 
electrical  system  and  electrical  system  laboratory  simulator.  To  keep  the 
system  cost  at  a  minimum,  the  program  was  tailored  so  the  requirements  met  as 
closely  as  possible  the  existing  electrical  and  DAIS  system  requirements  and 
applicable  hardware  and  software  available  at  the  AFWAL  Aero  Propulsion  and 
Avionics  Laboratories.  Also,  during  Task  1  an  evaluation  of  the  Aero 
Propulsion  and  Avionics  Laboratories  and  equipment  was  made.  This  evaluation 
helped  to  arrive  at  a  cost  effect  design  of  the  laooratory  simulator  through 
utilization  of  existing  hardware. 

In  Task  2  each  of  3  data  bus  architectures  (single  integrated  bus, 
hierarchical  integrated  bus,  separate  dedicated/non-integrated  bus)  were 
configured  with  options  ranging  from  all  computational  capability  residing  in 
the  digital  p'x.assor  (mission  computer)  to  most  of  the  processing  relegated 
to  remote  terminals.  Based  on  these  options,  AEPS  conceptual  designs  were 
prepared.  A  tabulation  of  all  the  relevant  parameters  including  processor/bus 
loading,  reliability,  memory,  and  cost  was  made.  The  baseline  for  the 
architectural  studies  was  the  separate  dedicated/non-integrated  data  bus. 
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Figure  1.  Phase  I  Program  Flow  Chart 


Both  the  hierarchical  integrated  bus  and  the  single  integrated  bus  were 
evaluated  against,  this  baseline.  Based  on  the  architectural  trade  studies, 
one  of  the  three  control  architectures  was  recommended  for  preliminary  design. 

In  Task  3  a  preliminary  design  of  the  electrical  system  with  the  selected 
architecture  was  conducted.  System  block  diagrams,  functional  flow  diagrams, 
data  flow  diagrams  and  key  event/timing  diagrams  were  prepared  for  the 
electrical  system.  Draft  specifications  for  the  hardware  and  software  for  the 
various  components  of  tK>  system  were  also  prepared.  A  preliminary  hazard 
analysis  of  the  system  was  conducted  and  a  detailed  development  plan  for  Phase 
II  is  prepared. 

Two  reports  were  published  covering  the  results  of  Phase  I.  Reoort 
AFWAL-TR-81-2058  (Reference  4)  covers  Tasks  1  and  2  and  >eport 
AFWAL-TR-81-2128  (Reference  5)  covers  Task  3. 

The  program  flow  chart  for  Phase  II  is  shown  in  Figure  2. 

During  Task  1  the  uetail  design  of  the  electrical  power  generation  and 
distribution  system  was  completed,  based  on  the  preliminary  design  conducted 
in  Phase  I,  Task  3.  Documents  prepared  included  the  Advanced  Electrical  Power 
System  (AEPS)  system  specification,  system  safety  analysis,  and  hardware  and 
software  specifications. 

During  Task  2  the  detail  design  of  the  laboratory  simulator  to  be  used  for 
electrical  system  evaluation  was  conducted.  Overall  simulator  specifications 
along  with  hardware  and  software  specifications  for  the  support  equipment  were 
prepared. 

Task  3  covereJ  investigations  of  multiple  data  bus  architectures  and  included 
definition  of  system  requirements,  trade  study  evaluation  of  the  alternatives, 
and  conceptual  desigr  of  a  multibus  system  including  the  simulator  support 
hardware  and  software. 

This  Final  Technical  Report  summarizes  Phase  I  and  covers  the  results  of  Phase 
II. 
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SECTION  II 


REQUIREMENTS  ANALYSIS 


1.  ELECTRICAL  SYSTEM  REQUIREMENTS 


Design  options  were  developed  for  an  electrical  power  system  for  a  small 
tactical  two  engine  aircraft  with  advanced  avionics  ard  fly-by-wire  (FBW) 
flight  controls.  The  following  assumptions  were  made  to  arrive  at  the 
electrical  system  requirements: 

o  2  Engine  Driven  Generators 
o  1  Flight  Operable  Auxiliary  Generator 
o  Mission  Completion  With  1  Main  Generator 
o  Safe  Return  With  Auxiliary  Generator 
o  Triple  Redundant  Fly-By-Wire  Flight  Control  System 
c  FBW  Electronics  will  be  Powered  by  DC  Power 
o  Solid  State  Distribution 


A  primary  generator  is  drivei  by  each  engine.  The  auxiliary  generator  is 
driven  by  a  flight  operable  auxiliary  power  unit. 


The  electrical  power  system  requirements  include  provisions  to  interface  with 
the  following  subsystems. 


Automatic  Flight  Control 

Auxiliary  Power 

Communications 

Crew  Escape 

Engines 

Environmental  Control 
Flight  Controls 


Fuel 

Hydraulic  Power 
Instruments 
Landing  Gear 
Life  Support 
Navigation 
Stores  Management 


The  degree  to  which  the  electrical  power  system  interfaces  with  other  airplane 
systems  varies.  For  some  subsystems,  such  as  automatic  flight  controls,  the 
interface  will  be  only  to  provide  power  and  caution  and  warning  indication. 
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For  other  subsystems,  such  as  envi ronnvental  control,  allocations  were  made  for 
more  extensive  interfacing,  such  as  on/off  control  of  equipment  and  sensor 
data  communication. 

a.  Load  Analysis 

Several  aircraft  with  different  missions  were  surveyed  with  the  intent  of 
determining  the  effect  of  the  mission  on  the  generation  capacity  (Reference 
4).  The  survey  showed  that  the  fighter,  electronic  warfare,  and  fighter 
bomber  missions  required  the  most  electrical  power.  The  power  requirements 
were  also  dependent  on  the  number  of  crew  members. 

The  trend  for  new  aircraft  is  toward  more  electrical  power  generation 
capacity.  This  is  the  result  of  increased  sophistication  in  avionics, 
weapons,  and  flight  control  systems.  Aircraft  dedicated  to  electronic  warfare 
missions  require  qreater  amounts  of  power.  Next  to  the  electronic  warfare 
mission,  the  fighter  and  fighter  bomber  aircraft  have  the  highest  power 
requirements. 

A  load  analysis  for  a  two  engine  tactical  aircraft  was  developed.  The 
analysis  is  based  on  the  air-to-surface  fighter  which  Boeing  is  studying.  The 
load  analysis  encompasses  the  fighter  and  fighter-bomber  missions  and  also  has 
some  ECM  capability.  A  load  profile  developed  from  the  analysis  is  shown  in 
Figure  3.  The  load  analysis  is  summarized  in  Table  1. 


TABLE  1.  ELECTRICAL  LOAD  ANALYSIS  SUMMARY 


MAXIMUM  CONNECTED 
LOAD 

SUSTAINED  PEAK  EMERGENCY 
LOAD 

TOTAL  AC  POWER 

58477  VA 

12577  VA 

TOTAL  DC  POWER 

7805  WATTS 

2630  WATTS 

TRU  LOSSES 

1377  WATTS 

465  WATTS 

TOTAL  TRU  INPUT  POWER 

9182  WATTS 

3095  WATTS 

TOTAL  AC  AND  DC  POWER 

67659  VA 

15672  VA 

in  v  fa 


AIRPLANE  MISSION  SEGMENTS 

Figure  3.  Electrical  Load  Profile 


b.  Generation  System 


Using  the  load  analysis  and  the  mission  effects  analysis  as  a  base,  the 
generation  and  distribution  system  was  sized.  The  equipment  complement  is 
shown  below. 


2- 60  KVA  115/200  VAC  Generators 

1-20  KVA  115/200  VAC  Auxiliary  Generator 

3- 100  Amp  28  VDC  Transformer  Rectifier  Units 

Two  60  KVA  main  generators  allow  mission  completion  with  one  generator  out. 
Three  100  amp  transformer-rectifier  units  (TRU)  provide  the  system's  DC 
power.  The  TRUs  are  sized  to  provide  power  for  all  connected  loads.  Two  TRUs 
wili  provide  enough  DC  power  for  mission  completion. 


Based  on  the  circuit  breaker  counts  of  three  aircraft  and  the  Reference  6 
study,  the  number  of  solid  state  power  controllers  (SSPCs)  selected  for  this 
aircraft  was  500,  distributed  as  shown  in  Table  2.  Loads  requiring  SSPCs 
larger  than  7.5A  AC  or  20A  DC  are  controlled  by  discretely  packaged  SSPCs  or 
electromechanical  power  controllers  (EMPCs). 


TABLE  2.  SOLID  STATE  POWER  CONTROLLER  DISTRIBUTION 

115  VAC 


SIZE 


PERCENT  TOTAL 


2A 

3A 

5A 

7.5A 


31.5 

8.5 

7 

3 


28  VDC 


SIZE 


PERCENT  TOTAL 


2A 

3A 

5A 

7.5A 

10A 

15A 

20A 


37 

6.5 
2 

2 

1.5 
.5 
.5 
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c.  Distribution  System 


The  distribution  system  consists  of  distributed  electrical  load  management 
centers  (ELMCs).  Previous  studies  (References  6  and  7)  have  shown  that  this 
distributed  concept  lowers  vulnerability  to  combat  damage  and  in  some  cases 
lowers  total  system  weight  when  compared  to  a  single  centralized  distribution 
center.  Individual  loads  are  connected  to  the  ELMCs  rather  than  to  the  main 
electrical  power  buses  as  in  conventional  electrical  systems.  Power  to  the 
loads  is  controlled  by  SSPCs  housed  in  the  ELMC. 

Five  ELMCs,  in  the  left  and  right  forward  avionics  bay,  left  and  right  wing 
area  and  in  the  cockpit  area,  provide  coverage  for  the  entire  aircraft. 

The  primary  functions  of  the  ELMC  are  to  house  the  SSPCs  and  interface  the 
SSPCs  to  the  data  bus.  To  maximize  the  utility  of  each  box  on  the  data  bus, 
the  ELMC  will  include  additional  functions  such  as  those  incorporated  in  RTs. 
This  will  minimize  the  number  of  boxes  on  the  data  bus.  Additional 
capabilities  included  in  the  ELMCs  are  analog-to-digital  (A/D)  conversion  and 
discrete  input/output  (I/O). 

The  ELMCs  handle  15^  of  the  system's  discrete  I/O  data  transfer.  Remote 
terminals  (RTs)  handle  80“  of  the  discrete  I/O  data  transfer  and  the  remaining 
is  allocated  to  the  generator  control  units  (GCUs).  Preliminary  design  of 
an  RT  indicates  a  capacity  of  approximately  250  inputs  and  118  ouputs  can  be 
packaged  in  a  4  MCU  (1/2  ATR)  size  box.  Based  on  such  a  design,  three  RTs  are 
required  to  handle  the  I/O  requirements  of  the  system. 

d.  Flight  Critical  Power 

Asa  design  philosophy,  each  channel  of  the  flight  control  system  must  have 
its  own  independent  power  source.  These  sources  may  be  cross  tied  for 
additional  redundancy.  For  a  triple  redundant  flight  control  system,  three 
independent  power  sources  are  thus  required.  With  DC,  this  provision  is 
easily  met  by  using  three  TRUs.  With  AC,  the  main  generators  provide  two 
sources.  A  third  source  car«  be  an  inverter  powered  from  a  DC  bus.  A  drawback 
to  using  AC  power  is  the  lack  of  a  simple  method  for  providing  uninterruptible 
power  to  the  flight  critical  equipment.  With  DC  power,  this  is  accomplished 
by  paralleling  the  sources. 
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DC  power  is  recommended  for  the  flight  critical  systems.  In  the  selected 
concept  (Figure  4) ,  a  flight,  critical  bus  is  provided  in  each  ELMC.  Each  bus 
is  powered  by  its  own  TRU.  Backup  power  is  provided  by  a  battery  which  is 
paralleled  with  the  TRU.  Any  number  of  flight  critical  equipments  can  be 
connected  to  the  bus;  however,  where  redundancy  is  required,  such  a'  a  triple 
redundant  flight  control  system,  only  one  channel  of  equipment  is  connected  to 
each  bus.  Having  a  flight  critical  bus  in  the  LLMC  provides  more  versatility 
and  reduces  the  number  of  load  feeders.  The  vulnerability  of  the  load  due  to 
the  sinqle  feeder  is  minimized  by  short  feeder  lengths  resulting  from  having  5 
ELMCs  distributed  throughout  the  aircraft. 

e.  Power  Bus  Configuration 

The  selected  electrical  power  bus  configuration  is  shown  in  Figure  5.  Only 
three  of  the  five  ELKls  are  shown.  Bus  ties  are  incorporated  in  this 
configuration.  In  the  AC  system,  the  bus  ties  eliminate  the  need  for  separate 
power  feeders  for  the  auxiliary  generator.  The  auxiliary  generator  supplies 
power  to  the  ELMCs  through  the  main  generator  buses.  The  DC  bus  ties  allow 
the  TRUs  to  be  paralleled  and  to  share  power  feeders. 

f.  System  Control  and  Protection 

The  system  control  and  protection  provides  for  automatic  operation  and 
coordinated  fault  isolation.  Control  and  protection  is  sectionalized  into  the 
following  areas:  generator,  distribution,  and  loads.  The  objectives  of 
control  and  protection  is  to: 

o  Reduce  crew  work  load 
o  ’ncrease  flexibility 
o  Increase  survivability 
o  Increase  probability  of  mission  success 

The  reduced  crew  work  load  is  achieved  by  automation.  The  use  of  digital 
processors  and  data  bus  communication  lines  link  the  various  subsystems  and 
allow  coordination  of  most  of  the  components  of  the  electrical  system  with 
other  aircraft  subsystems. 
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Flexibility  is  achieved  by  programmable  digital  processors  which  control  the 
system  and  the  individual  SSPCs.  The  capability  to  reconfigure  the  system 
qreatly  enhances  system  flexibility. 

Increased  survivability  and  probability  of  mission  success  are  achieved  by 
coordination  of  all  electrical  functions  and  a  comprehensive  load  management 
program.  Automatic  switching  provides  for  fast  fault  isolation,  bus 
switching,  and  load  shedding.  Load  managment  diverts  power  to  flight  and 
mission  essential  loads  in  the  event  of  a  decrease  in  available  power. 

The  control  and  protection  functions  for  both  the  main  and  the  API)  generator 
are  shown  below. 


Generator  Protection 


o  over /under  frequency  o  over/under  voltage 

o  open  phase  o  input  underspeed 

o  differential  protection  o  failed  rotating  rectifier 

o  overload 

Generator  Control 

o  voltaqe  regulation 

o  frequency  regulation 

o  generator  contactor 


For  advanced  aircraft  which  depend  on  electrical  power  for  mission  completion 
and  flight  control,  protection  and  control  of  the  primary  generating  system  is 
critical.  To  provide  maximum  fault  isolation  and  to  provide  the  necessary 
response  time  for  the  control  of  an  aircraft  generator,  the  control  and 
protection  of  the  generator  is  accomplished  by  the  GCU  and  is  not  delegated  to 
the  system  processors.  The  control  and  sensor  lines  to  the  generator  are 
hardwired.  The  GCU  is  connected  to  the  data  bus.  However,  the  generator 
control  and  protection  functions  operate  independently  of  data  bus  service 
functions.  This  isolates  the  generator  from  data  bus  failures.  The  data  bus 
is  used  to  carry  data  such  as  overload  instructions,  maintenance  information, 
and  fault  indications,  between  the  GCU  and  the  system  processors.  Having  the 
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GCU  hardwired  to  the  generator  also  facilitates  system  startup  from  a  "dead" 
airplane.  In  addition,  loads  necessary  during  startup  are  controlled  by  _SPCs 
which  are  in  the  closed  state  when  no  control  signal  is  present. 

The  distribution  system  includes  the  main  buses,  external  power  receptacles 
and  distribution  feeders.  The  function  of  the  distribution  protection  system 
is  mainly  to  provide  fault  isolation.  The  protection  and  control  functions 
associated  with  the  distribution  system  are  shown  below. 

Protection 

o  fault  protection  and  isolation 
o  abnormal  external  power  protection 

Control 

o  bus  tie  breaker  control 
o  external  power  breaker  control 
o  power  distribution  to  ELMCs 

The  versatility  and  survivability  of  the  aircraft  is  enhanced  with  the 
multiplexed  data  bus  control  of  the  loads.  All  loads  are  under  system  control 
and  status  of  the  loads  is  constantly  monitored.  Load  control  is  accomplished 
by  the  solution  of  Boolean  control  equations.  There  i  one  equation  for  each 
load.  The  equation  takes  the  form  shown  below. 

C  =  L  P  (R  +  Q) 

C  =  SSPC  On/Off  Control  Signal 
l.  =  Trip  latch 
P  =  Priority  Signal 

R  =  Request  for  Power  (Solution  of  a  Boolean  Equation) 

Q  =  Test  Request  (Such  as  Ground  Test) 

The  variable  R  is  the  output  of  a  system  equation  consisting  of  inputs  from 
the  system's  RTs  and  ELMCs.  The  priority  signal,  P,  is  used  to  implement  load 
management.  Sixteen  load  management  levels  are  available.  Each  level 
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represents  a  different  set  of  priority  signals  for  the  SSPCs.  At  each  level, 
each  SSPC  has  an  assigned  Driority,  P.  A  P  set  to  "0"  inhibits  or  commands 
the  SSPC  to  turn  off.  A  "1"  allows  the  SSPC  to  turn  on.  The  relationship  of 
the  P  variable  and  the  load  management  levels  can  be  visualized  as  a  16  x  500 
matrix  (500  SSPCs  in  the  system)  of  "Is"  and  "0s".  Depending  on  the  load 
management  level  implemented,  a  preselected  combination  of  500  "Is"  and  "Os" 
are  substituted  for  the  variable  P  in  the  SSPC  control  equations.  The  load 
management  matrix  is  shown  in  Figure  6.  Various  system  parameters  are  used  to 
logically  select  one  of  the  sixteen  load  management  levels.  The  level  can 
also  be  selected  manually.  Figure  7  shows  parameters  which  are  used  in 
determining  the  load  management  level. 

g.  Applicability  of  J73/I  (JOVIAL) 

The  evaluation  of  the  applicability  of  JOVIAL  higher  order  language  to 
electrical  systems  was  investigated.  A  literature  search  aimed  at  a 
comparison  of  the  efficiency  of  assembly  and  higher  order  languages  was 
cciducted.  The  actual  coding  of  two  typical  power  control  routines  in  both 
JOVIAL  and  assembly  language  was  done  for  comparison.  The  analyses  were 
performed  using  J73/I;  however,  J73/I  has  since  been  superceded  by  J 73 .  The 
changes  made  in  the  language  have  been  in  the  area  of  syntax  and  data  type 
conversion.  Also,  a  few  new  functions  have  been  added.  The  differences 
between  J73/I  and  J73  are  minor  and  do  not  affect  the  results  of  the  analyses. 
Based  on  the  results  of  the  literature  search  and  codinq  evaluation,  it  was 
concluded  that  J73  should  be  used  as  the  programming  langu'ge. 

h.  Controls  and  Displays 

An  analysis  was  done  to  establish  the  requirements  for  the  controls  and 
displays  of  the  electrical  system.  The  aim  of  the  design  is  to  minimize  the 
controls,  and  only  display  that  information  which  is  essential  for  the  pilot 
to  maintain  aircraft  safety  and  to  assure  mission  success. 

In  keeping  with  this  objective,  no  panel  indicators  are  provided  for 
individual  SSPC  status  or  trip  indication  and  individual  SSPC  reset  control. 
Indication  of  a  failed  or  tripped  SSPC  appears  on  the  appropriate  subitem 
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SELECT 

LOAD  MANAGEMENT 
LEVEL 


Hgure  7.  Load  Management  Level  Selection 


warning  panel  or  equipment  war.ing  panel.  A  control  panel  is  required  for  the 
DAIS  processors.  It  provides  power  to  the  appropriate  processor  during 
startup  and  restart  control  for  any  architecture. 

A  CRT  display  dedicated  to  the  electrical  system  is  not  feasible  in  a  two 
engine  tactical  aircraft;  however,  it  is  feasible  to  display  electrical  system 
data  on  the  avionics  display  units.  This  integrated  CRT  display  concept  is 
possible  with  the  integrated  data  bus  architecture  and  the  hierarchical  data 
bus  architecture.  An  example  of  this  integrated  controls/displays  concept, 
which  uses  existing  DAIS  hardware,  is  shown  in  Figure  8.  Only  key  system 
failures  which  affect  the  mission  success  are  displayed  on  the  CRT. 

2.  CONTROL  SYSTEM  REQUIREMENTS 


Processing,  bus  loading,  and  response  time  requirements  are  defined  in  this 
section.  Following  are  the  major  assumptions  for  defining  the  requirements 
for  the  i ntegrated  power  system  control : 

a)  Maximum  use  of  Digital  Avionics  Information  System  (DAIS)  concepts 
(Reference  8) 

-  MIL-STD-1553B  multiplexed  data  bus 

-  RTs  per  specification  SA  321301 

-  DAIS  executive  with  synchronous  bus  protocol 

-  Use  of  Jovial  higher  order  language  for  power  system  application 
software 

b)  Separate  AN/AYK-15A  processor  for  power  system  cont.  >J . 

c)  Hardware  connected  to  the  1553B  bus. 

-  5  ELMCs  with  100  SSPCs  each 

-  3  Power  system  RTs 

-  2  GDIs 
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Processing  requirements  for  the  power  system  were  based  on  the  B-l  EMUX 
specification  (Reference  9).  Using  the  number  of  SSPCs  as  a  complexity 
measure,  the  number  and  type  of  equations  necessary  for  the  power  system  in  a 
tactical  fighter  was  determined  by  scaling  the  equation  count  for  the  B-l 
aircraft  by  the  ratio  of  the  SSPC  requirement  for  the  fighter  to  that  required 
in  the  case  of  the  B-l  EMUX. 

The  processing  requirements  can  be  separated  into  three  categories  of 
equations  as  described  below. 

Category  I:  These  are  power  request  equations  and  are  of  the  form  Z=R  where  R 
may  ta^e  one  of  the  fol’ owing  forms: 

Form  1  One  variable  of  the  Form  or  A,  or  the  value  "logic  1 

Form  2  Five  variables  arranged  in  any  valid  Boolean 
expression  with  each  variable  used  once  only 

Form  3  Twenty  variables  arranged  in  any  valid  boolean 
expression  with  each  variable  used  once  only 

Form  4  Two  hundred  variables  arranged  as  the  sum  of  products 
with  each  product  term  composed  of  no  more  than  six 
variables  with  no  variable  repeated  in  the  Boolean 
expression . 

There  will  be  208  form  1,  236  form  2,  45  form  3,  and  8  form  4  equations  for 
this  aircraft. 

Category  II:  There  are  500  SSPC  power  control  equations  of  the  form: 

C  =  IP  (R  +  Q) 

Where  R  is  a  Boolean  expression  of  Form  1,  2,  3,  or  4  listed  above;  P  is  a 
single  variable;  L  is  the  solution  to  the  latch  equation  and  Q  is  test  request 
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j. 


Cateqory  III:  There  are  500  power  system  status  equations  of  the  form: 

I  =  (L  +  PX) 

Where  L  is  as  defined  in  Category  II  above;  P  and  X  are  single  variables 
available  to  the  system  designer  for  definition, 

b.  Input/Output  Requirements 

In  the  power  system,  the  input/output  consists  of  the  data  and  traffic 
transmitted  between  the  power  system  processor  and  its  ELMCs  and  RTs  in  order 
to  accomplish  the  power  system  management  and  control  functions.  The  I/O 
requirements  were  determined  by  scaling  the  B-l  EMUX  requirements  by  the  ratio 
of  the  SSPC  count.  The  discretes  transmitted  on  the  bus  consist  of  sensor, 
SSPC  status,  system  control  and  status,  RT  sync,  and  mode  control  information. 

The  requirements  for  this  study  were  2096  discrete  inputs  and  1041  discrete 
outputs.  It  was  assumed  that  the  GCU  interface  with  the  power  system 
processor  would  require  approximately  50  discretes  for  either  input  or 
output.  All  remaining  discretes  were  uniformly  distributed  among  the  ELMCs 
and  RTs.  That  is,  each  device  connected  to  the  data  bus  with  the  exception  of 
the  GCUs,  contributes  equally  to  the  total  discrete  input  and  output 
requirements. 

c.  Response  Time 

In  order  to  compute  the  processor  loading  and  data  bus  loading,  the  response 
time  of  the  system  must  be  known.  Response  time  refers  to  the  maximum  time 
required  to  detect  a  change  in  an  event,  Drocess  the  information  and  then  send 
a  response  on  the  data  bus.  A  bi modal  response  time  was  used  in  this  study. 
For  the  power  system,  approximtely  95%  of  the  discrete  data  must  be  received 
by  the  power  system  processor  (PSP),  processed,  and  the  results  must  be 
transmitted  within  300  ms.  The  remaining  5%  of  the  equations  and  discrete 
data  must  be  processed  for  a  50  ms  response  time.  The  50  ms  response  time 
pertains  to  events  which  require  power  bus  switching  for  power  distribution 
reconfiguration. 
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d.  Avionics  Bus  Loading 


The  avionics  bus  loading  is  necessary  so  the  bus  loading  capacity  for  an 
integrated  power  and  avionics  data  bus  architecture  could  be  sized.  In  order 
to  determine  realistic  bus  loading  for  the  avionics  system,  the  following 
aircraft  missions  were  studied:  fighter,  attack,  reconnaissance,  trainer, 
electronic  warfare,  and  fighter  bomber. 

In  order  to  establish  a  representati ve  avionics  baseline  bus  loading,  model 
subsystems  with  average  complexity  were  selected.  Data  for  the  weapons 
delivery  function  (fire  control  computer,  stores  management,  fire  control 
radar,  and  laser  set),  inertial  navigation  system,  and  air  data  computer  were 
all  taken  from  published  data  for  the  F-16.  F-16  Control  and  Display  data  was 

used  since  no  fighter-bomber  control  and  display  data  was  available.  The 
baseline  control  and  display  subsystem  therefore  consists  of  a  fire  control 
and  navigation  panel,  head-up-display  (HUD),  and  radar  display.  Electronic 
counter  measures  (ECM),  imaging,  and  communications  data  bus  loading  was  based 
on  data  developed  at  Boeing  for  a  multi-role  bomber.  The  ECM  subsystem 
function  is  assumed  to  consist  of  flare  and  chaff  dispersal.  The  imaging 
subsystem  baseline  consists  of  a  forward  looking  radar. 

Perturbations  from  the  baseline  in  the  form  of  increased  complexity  for  the 
control  and  display,  inertial  navigation  system,  ECM.  and  imaging  subsystems 
for  the  reconnaissance,  trainer,  and  electronic  warfare  missions  were 
examined.  Significant  complexity  increases  in  the  inertial  navigation  system 
and  the  imaging  subsystem  exist  for  the  reconnaissance  mission. 

Reconnaissance  missions  are  assumed  to  require  a  very  accurate  irertial 
navigation  system  and  the  imaging  subsystem  would  contain  side  looking  radar, 
infra-red  mapping  equipment,  high  resolution  cameras,  and  TV  cameras  as  well 
as  forward  looking  radar.  The  increase  in  data  bus  loading  incurred  by  these 
more  complicated  subsystems  is  expected  to  be  neutralized  by  the  absence  of  a 
weapons  delivery  capability. 

In  the  case  of  the  trainer  a  more  complicated  control  and  display  subsystem  is 
anticipated  because  of  the  requirement  for  dual  controls  and  displays,  and  an 
additional  monitor  function  for  one  of  the  pilots.  The  increase  in  the  bus 
traffic  is  estimated  to  be  less  than  20%  for  this  subsystem. 
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The  electronics  warfare  mission  represents  perhaps  the  greatest  potential  for 
increased  data  bus  traffic  from  the  baseline  due  to  the  large  amount  of  data 
needed  to  identify  threats  and  jamming  as  appropriate.  Data  from  the 
multi -role  bomber  study  indicates  that  EMC  can  add  8000  words/sec  to  bus 
traffic.  Again  this  is  offset  by  a  lack  of  weapon  delivery  capability  for 
this  mission.  Using  the  F-16  data,  the  weapons  delivery  capability  would  add 
8975  words/sec  to  the  data  bus,  more  than  offsetting  the  ECM  traffic. 

Based  on  the  above  analysis,  the  number  of  words/sec  shown  in  Table  3  was 
selected  as  the  baseline  avionics  data  bus  loading  model.  The  percent  bus 
loading,  based  on  approximately  40,000  data  words/sec  maximum  bus  loading  for 
the  MIL-STD-1553B  data  bus,  was  36%. 

TABLE  3.  BASELINE  AVIONICS  DATA  BUS  LOADING 


SUBSYSTEM  WORDS/SEC 

Control  and  Display  661 

Weapons  Delivery  8975 

Inertial  Navigation  3350 

Air  Data  Computer  775 

Communications  128 

ECM  205 

Imaging  Radar  128 

14,222 


3.  TECHNICAL  ANALYSIS 

A  technical  analysis  was  performed  on  the  three  separate  architectures 
considered  for  electrical  control.  These  three  architectures  are  shown  in 
Figure  9  and  are  described  below: 

a)  Integrated:  The  electrical  control  system  is  on  the  same  bus  as  the 
avionics. 

b)  Hierarchical:  The  electrical  control  system  is  on  a  separate  bus  but 
is  connected  to  the  avionic  bus  through  an  interbus  processor. 

c)  Non-Integrated:  The  electrical  control  system  is  not  connected  to  the 
avionic  system  by  any  multiplex  data  bus. 
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C:  NON- INTEGRATED  POWER  BUS 


Figure  9.  Data  Bus  Architecture  Configurations 


For  each  of  these  architectures  the  following  analyses  were  performed: 

a)  Processor  loading:  This  is  calculated  as  the  total  time  required  to 
calculate  the  necessary  set  of  logic  equations  in  a  minor  cycle 
divided  by  the  time  in  a  minor  cycle.  The  accepted  limit  for 
processor  loading  is  50%. 

b)  Bus  Loading:  This  is  calculated  as  the  time  required  to  transmit  the 
necessary  set  of  data,  including  overhead,  in  a  minor  cycle  divided  by 
the  time  in  a  minor  cycle.  The  accept'  1  limit  for  bus  loading  is  50%. 

c)  Memory  Requirements:  The  total  memory  requirements  for  the  logic 
equations  and  the  executive  is  calculated. 

d)  Reliability:  an  arcnitectural  reliability  for  comparison  of  the 
integrated  and  hierarchical  concepts  is  calculated. 

e)  Number  of  Processors  Required:  An  estimate  of  the  total  number  of 
processors  is  qiven  for  each  architecture. 

f)  Smart  RTs:  The  effect  on  processor  loading  and  bus  loading  is 
analyzed  using  distributed  processing  with  smart  PTs. 

a.  General  Assumptions 

The  analysis  of  the  three  data  bus  architectures  was  made  based  on  the 
assumptions  listed  below.  The  assumptions  (a)  through  (j)  apply  to  all  of  the 
three  architectures  studied,  whereas  ( k )  through  (n)  apply  only  to  the 
integrated  data  bus  architecture. 

a)  Response  *ime  is  defined  to  be  the  time  required  for  a  data  change  in 
one  RT  to  ue  received  by  the  processor,  processed,  and  transmitted  to 
all  other  RTs  that  require  the  data. 

b)  Bus  I/O  and  processing  are  bimodal  to  meet  separate  response  times  of 
50  msec  and  300  msec.  The  messages  that  require  a  50  msec  response 
time  are  5  percent  of  the  total. 

c)  The  system  uses  an  MIL-STD-1553B  multiplex  data  bus. 

d)  All  bus  transmissions  are  terminal -to-controller  or  control ler-to- 
terminal.  These  are  not  terminal -to-terminal  transmissions. 

e)  All  bus  transmissions  are  synchronous. 

f)  The  system  runs  at  128  minor  cycles  per  second.  This  provides  7.8125 
msec  in  each  minor  cycle. 
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g)  All  remote  terminals  in  the  system  receive  the  minor  cycle 
synchronization  mode  code  each  minor  cycle. 

h)  All  data  words  transmitted  on  the  bus  are  packed  12  data  bits  per  16 
bit  word.  This  will  allow  expansion  of  4  bits  per  word. 

i)  For  each  arcr.itecture,  there  is  one  power  system  processor.  This 
processor  is  a  MIL-STD-1750  machine  with  128  K  words  (16  bits  each)  of 
memory . 

j)  For  each  architecture  there  are  ten  power  RTs.  This  includes  5 
ELMCs.  In  the  smart  RT  configurations,  the  5  ELMCs  have  a  Z8002 
microprocessor  as  the  processing  element. 

k)  The  power  system  processor  is  a  remote  processor  on  the  data  bus.  The 
bus  controller  is  the  avionics  processor. 

l)  All  power  applications  processing  occurs  in  the  power  system 
processor.  There  is  no  power  processing  in  the  avionics  processor(s). 

m)  Bus  loading  for  the  avionics  I/O  is  36%. 

n)  The  avionic  bus  controller  processor  sends  a  minor  cycle 
synchronization  mode  code  to  the  power  system  processor  and  to  each  of 
the  power  RTs  every  minor  cycle.  The  bus  time  required  to  do  this  is 
included  in  the  avionics  bus  load. 

b.  Processor  Loading 

Processor  loading  is  defined  as  the  amount  of  time  within  a  minor  cycle  that 
the  processor  is  busy  executing  application  and  executive  code.  The  loading 
of  the  power  system  processor,  smart  RT  with  Z8002  microprocessor,  and 
executive  loading  are  all  discussed. 

Processor  loading  was  calculated  for  both  dumb  RT  and  smart  RT 
configurations.  In  the  dumb  RT  configuration  the  power  system  processor 
calculates  all  equations.  In  the  smart  RT  configuration  the  ELMC  RTs 
calculate  the  category  II  and  III  equations  and  the  processor  calculates  only 
the  category  I  equations. 

Equation  calculation  is  bimodal  to  meet  response  times  of  50  msec  and 

300  msec.  In  a  dumb  RT  configuration,  5%  of  the  calculations  are  spread  over 

2  minor  cycles  to  meet  the  50  msec  response  time  and  95%  of  the  calculations 
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are  spead  over  32  minor  cycles  to  meet  the  300  msec  response  time.  In  a  smart 
RT  configuration,  5%  of  the  calculations  are  spread  over  2  minor  cycles  and 
of  the  calculations  are  spread  over  16  minor  cycles. 

In  the  smart  RT  configuration,  each  of  the  5  ELMC  RTs  has  a  Z8GQ2  processing 
element.  Only  the  processing  time  for  the  500  SSPC  complement  was  calculated 
for  the  smart  RTs.  The  Category  II  and  III  equations  are  divided  equally 
between  the  5  smart  RTs.  As  with  power  processor  loading,  the  calculation  of 
equations  is  bimodal  to  meet  response  times  of  50  and  300  msec.  The 
processing  load  for  each  RT  is  21%  with  5%  of  the  processing  spread  over  2 
minor  cycles  and  95%  of  the  processing  spread  over  16  minor  cycles. 

Because  each  of  the  three  architectures  requires  a  different  executive,  the 
processing  time  required  by  the  executive  is  different  for  each  architecture. 

In  the  integrated  architecture ,  the  executive  is  responsible  only  for  actions 
local  to  the  power  system  processor.  It  is  not  responsible  for  bus  control  or 
system  actions.  In  the  hierarchical  and  non-integrated  architctures ,  the 
power  system  processor  has  an  executive  that  is  responsible  for  both  system 
actions  and  local  actions.  In  addition  the  hierarchical  power  processor 
executive  has  slightly  more  processing  requirements  as  a  result  of  being  a 
remote  on  the  avionics  bus.  In  relation  to  one  another,  the  hierarchical 
executive  requires  the  most  overhead,  the  non-integrated  executive  is  second 
and  the  integrated  executive  requires  the  least. 

The  actual  percentage  of  processor  loading  during  a  minor  cycle  required  by 
the  executive  is  dependent  on  the  type  of  executive  as  stated  above,  and  on 
how  the  applications  software  is  structured  and  the  amount  of  executive 
services  the  application  software  requires.  The  more  applications  tasks  there 
are,  the  more  overhead  the  executive  requires.  A  general  assumption  is  that 
the  executive  overhead  for  servicing  applications  tasks  is  about  20%  of  the 
applications  processor  load. 

c.  Data  Bus  Loading 

Data  bus  loading  is  defined  as  the  time  required  to  transmit  the  required 
data,  including  overhead,  divided  by  the  total  time  available.  The  overhead 
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included  in  the  bus  loading  analysis  is  inter-message  gap  time  and  message 
response  time.  Bus  loading  was  calculated  for  dumb  and  smart  RT 
configurations  in  each  of  the  three  architectures  for  the  four  different  SSPC 
complements.  The  data  bus  I/O,  like  the  processor  loading,  is  bimodal  to  meet 
response  times  of  50  and  300  msec. 

d.  Memory  Requi rements 

Estimates  of  memory  requirements  were  made  for  the  power  system  processor  and 
for  a  smart  RT.  The  elements  that  are  competing  for  memory  are  listed  as 
follows: 

o  executable  code  for  applications  equations 
o  other  executable  code  for  application 

o  application  data 

o  executive  code 

o  executive  data 

The  memory  requirements  for  equation  calculations  can  be  determined  exactly 
but  only  estimates  can  be  made  for  the  others.  The  memory  requirement  for  the 
equations  was  determined  by  coding  representative  equations  in  the  J73/I 
higher  order  lanquage. 

Other  executable  code  for  applications  include  such  things  as  control  logic 
for  the  equations  themselves  and  applications  processing  other  than 
equations.  The  memory  required  for  this  is  totally  dependent  on  the  design 
and  structure  of  the  applications  software  and  cannot  be  accurately  determined 
here. 

Estimates  can  be  made,  however,  for  the  memory  requirements  of  the  executive 
and  the  executive  data  base.  The  power  system  processor  in  each  architecture 
type  requires  a  different  executive  size  and  executive  data  base  size. 
Estimates  on  the  executive  size  are:  3000  words  for  the  integrated  power 
processor,  7000  words  for  the  hierarchical  processor  and  5000  words  for  the 
non-integrated  power  system  processor.  The  executive  data  base  is  dependent 
on  the  type  of  executive  and  the  structure  of  the  application  software.  A 
large  number  of  application  tasks,  events,  etc.  results  in  a  larger  executive 
data  base.  A  conservative  estimate  on  the  size  of  the  executive  data  base  for 
an  average  set  of  applications  tasks  is  5000  words. 
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e.  Reliability 

Reliability  comparisons  for  the  three  architectures  are  made  using  the 
generalized  reliability  model.  Reliability  computed  is  not  an  overall  system 
reliability.  It  is  a  computer  architecture  reliability  and  its  main  purpose 
is  for  comparison  of  the  three  architectural  configurations. 

The  following  assumptions  were  used  in  the  reliability  analysis: 

a)  2.5  HR  mission  time  for  the  tactical  two  engine  airplane. 

b)  Processor  MTBF  -  3000  HRS:  This  MTBF  was  obtained  from  the  DAIS 
AN/AYK-15A  specification  in  Reference  10. 

c)  GCU  MTBF  -  4000  HRS:  obtained  from  Reference  6. 

d)  ELMC  MTBF  -  1159  HRS 

e)  RT  MTBF  -  2354  HRS 

f)  Connector  MTBF  =  1.8  x  106  HRS 

Assumptions  d-f  are  based  on  Harris  Corporation  hardware  experience. 

The  reliability  for  the  respective  architectures  was  calculated  and  is  shown 
below: 

Non-i ntegrated  -  0.984 
Integrated  -  0.976 
Hierarchical  -  0.976 

Due  to  the  high  reliability  of  the  connectors  and  since  an  equal  number  of 
elements  is  connected  to  the  data  bus  for  both  the  hierarchical  and  integrated 
architectures,  the  reliablity  is  the  same  for  these  two  configurations. 

f.  Results  of  the  Technical  Analysis 

The  major  conclusions  of  the  technical  analysis  performed  on  the  three 
architectures  are: 

a)  Processor  loading:  Smart  ELMCs  and  an  integrated  architecture  are 
necessary  to  meet  the  processing  requirements  for  a  two  engine 
tactical  aircraft. 
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b)  Bus  loading:  All  architectural  concepts  can  meet  the  two  engine 
tactical  aircraft  power  system  control  requirements  if  smart  ELMCs  are 

itcnrl  _ 

c)  Memory:  Smart  ELMCs  will  require  17%  more  memory  than  the  dumb  ELMC 
configurations  to  meet  the  equation  processing  requirements. 

d)  Reliability:  The  hierarchical  and  integrated  architectures  have 
identical  reliablity  due  to  the  high  reliablity  of  connectors. 

4.  ECONOMIC  ANALYSIS 

Both  software  and  hardware  costs  of  a  two  engine  tactical  aircraft  electrical 
power  control  system  architecture  were  examined.  Software  costs  are  for 
application  software  development  only.  These  costs  are  independent  of  the 
architecture  chosen.  Hardware  costs  are  relative  to  the  baseline  non- 
integrated  architecture.  Only  relative  hardware  costs  were  obtained  since 
absolute  costs  from  the  manufacturers  could  not  be  obtained  for  the  hardware 
at  this  early  stage  of  development.  The  effects  of  SSPC  count  ?nd 
architectural  differences  were  included  in  the  analysis. 

All  architectural  configurations  studied  have  identical  numbers  of  ELMCs,  RTs, 
and  GCUs.  The  major  differences  between  the  three  concepts  are  in  the 
processor  requirements. 

The  requirements  for  the  power  system  processor  for  the  non-integrated 
architecture  approach  can  be  met  by  the  nAIS  AN/AYK-15A  machine  both  in  terms 
of  hardware  and  software.  The  requirements  for  the  power  system  processor  for 
the  integrated  architecture  approach  can  also  be  met  by  the  DAIS  AN/AYK-15A 
except  that  the  executive  software  will  not  be  as  extensive  since  here  the 
avionics  processor  will  have  most  of  this  responsibility.  Thus,  the  software 
requirements  for  the  integrated  architecture  processor  are  20%  lower  than  that 
of  the  non-integrated  architecture  processor.  This  results  in  a  cost 
reduction  for  the  integrated  architecture  system  over  the  non-integrated 
architecture  system. 

For  the  hierarchical  architecture  additional  hardware  and  software  will  be 
required  to  provide  the  AN/AYK-15A  processor  with  the  capability  to  interface 
with  two  data  buses  and  perform  the  interbus  communications  in  addition  to  the 
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power  system  processor  functions.  The  interbus  communication  results  in  a  40?. 
increase  in  processor  executive  software  requirements.  This  increases  the 
cost  of  the  hierarchical  architecture  processor  hardware  and  software  ever  the 
n on-integrated  architecture  processor.  Therefore,  the  hierarchical 
architecture  system  will  cost  more  than  the  non-integrated  architecture 
system.  From  an  economic  standpoint  the  integrated  data  bus  architecture 
concept  is  considered  most  appropriate  for  a  two  engine  tactical  aircraft. 


SECTION  III 


CONCEPTUAL  DESIGNS 


1.  BUS  ARCHITECTURES 

Three  power  control  system  data  bus  architectures  were  configured  using  DAIS 
concepts  to  the  maximum  extent  possible.  In  order  to  examine  the  feasiblity 
of  integrating  the  power  system  control  function  into  the  DAIS  architecture, 
two  conceptual  designs  were  configured  which  have  varying  degrees  of 
integration  with  the  avionics  data  bus.  In  the  first  design,  the  integrated 
concept,  both  avionics  and  power  system  control  is  a*. :ompl i shed  using  a  common 
data  bus.  In  the  second  design,  the  hierarchical  concept,  a  separate  data  bus 
is  used  for  the  avionics  and  the  power  system  control.  The  power  system 
processor  is  connected  to  both  the  avionics  and  power  data  buses  and  performs 
the  additional  function  of  interbus  processing. 

The  third  design  is  the  dedicated  or  non-integrated  power  system  control 
concept.  In  this  arrangement  the  avionics  and  power  system  control  functions 
are  totally  separate  with  a  separate  data  bus  for  each.  Such  an  architecture 
probably  could  not  be  justified  for  a  light  tactical  fighter.  However,  this 
concept  was  used  as  a  baseline  for  comparing  the  two  aoproaches  described  in 
the  previous  paragraph  and  for  determining  power  system  control  requirements 
for  a  light  tactical  aircraft. 

a.  Data  Bus  Architectures 

All  the  data  bus  architectures  presented  in  this  section  are  based  on  the  DAIS 
configuration.  The  DAIS  architecture  consists  of  federated  processors 
communicating  with  each  other  and  the  other  system  elements  (sensors,  weapons, 
and  controls  and  displays)  through  a  standardized  multiplex  data  bus. 
Centralized  system  single-point  control  is  performed  by  a  processor  resident 
software  executive  the t  can  be  relocated  for  redundancy.  Applications 
software  is  structured  to  provide  modularity,  reliability,  and  transferability. 
This  system  architecture  is  flexible  to  accommodate  a  wide  variety  of  avionics 
configurations,  missions,  and  sensors,  which  provides  redundancy  to  improve 
availability,  and  accommodate  changes  in  technology. 
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The  basic  architecture  is  designed  for  a  broad  class  of  configurations  where 
the  number  of  processors  can  be  reduced  or  enlarged  depending  upon  the 
avionics  and  mission  requirements.  Standardization,  modularity,  and 
application  independent  executive  software  allows  adaptability  of  this 
architecture  to  a  broad  class  of  different  applications  as  well  as  to  making 
mission-to-mission  changes  in  a  particular  aircraft. 

Sensors,  weapons,  and  other  subsystems  are  selected  as  required  for  the 
particular  mission  and  connected  to  the  interface  modules  of  the  remote 
terminals  of  the  multiplex  system  or  connected  directly  to  the  multiplex  bus. 

b.  Non-integrated  Data  Bus  Architecture 

The  baseline  non-integrated  data  bus  architecture  is  shown  in  Figure  10.  The 
configuration  has  2  GCUs,  3  RTs,  5  ELMCs  and  one  DAIS  type  processor.  Power 
management  and  control  software  resides  in  this  processor.  In  the  case  of  a 
smart  ELMC  some  of  this  software  is  moved  to  the  ELMCs. 

The  major  advantages  of  this  architecture  as  compared  to  the  other  two 
candidates  are: 

a)  Simple  system  integration  and  test  -  due  to  the  separation  of  avionics 
and  power  control  functions. 

b)  Easily  expandable  with  minimum  software  impact  -  due  to  similarity 
with  DAIS  concept  and  existing  software  and  hardware  modularity. 

c)  Minor  changes  to  existing  DAIS  software  -  existing  software  for  DAIS 
is  "off  the  shelf"  and  only  an  application  software  package  needs  to 
be  written. 

The  major  disadvar  ~s  of  the  non-integrated  architecture  are: 

a)  Redundant  avionics  RT  interfaces  -  because  both  buses  are  physically 
separate,  avionics  signals  needed  in  power  system  management  require 
duplicate  interfaces  on  each  data  bus. 

b)  Additional  controls  and  displays  -  since  there  is  no  data  path  between 
the  avionics  and  power  control  systems,  multi -function  controls  and 
displays  already  developed  for  the  DAIS  concept  cannot  be  utilized. 
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Baseline  Non- Integrated  Architecture 


c)  Higher  bus  loading  -  because  avionics  signals  from  the  avionics  bus 
cannot  be  used,  these  must  be  obtained  by  duplicate  interfaces. 

d)  Additional  weight  -  due  to  redundant  DAIS  components  like  the  controls 
and  displays  and  bus  interface  hardware. 

c.  Integrated  Data  Bus  Architecture 

The  integrated  data  bus  architecture  combines  the  avionics  and  power  system 
processors  on  a  single  data  bus.  This  concept  is  shown  in  Figure  11.  The 
avionics  processor  acts  as  tha  bus  controller  for  the  entire  data  bus  and  is 
otherwise  dedicated  to  avionics  functions.  The  power  system  processor  shares 
the  same  1553B  data  bus  and  manages  and  controls  its  5  ELMCs,  3  RTs,  and  2 
GCUs.  Controls  and  displays  are  shared  both  by  the  power  and  avionics 
system.  The  major  advantages  of  this  concept  are: 

a)  Minor  changes  to  existing  DAIS  concept  -  in  this  configuration  the 
power  system  processor  acts  as  an  RT  and  all  executive  software  is 
"off  the  shel*".  Only  a  power  system  application  software  package 
needs  to  be  designed. 

b)  Least  power  and  weight  -  when  compared  to  the  other  two  concepts,  the 
integrated  approach  minimizes  the  redundant  use  of  DAIS  software  and 
hardware . 

c )  *  Le^s  memory  requirements  -  due  to  the  fact  that  the  power  system 

processor  is  an  RT  on  the  avionics  data  bus,  a  full  executive  is  not 
necessary. 

The  major  disadvantages  of  the  integrated  concept  are: 

a)  Interaction  of  the  power  and  avionics  systems  -  changes  to  either 
system  can  effect  the  other  as  the  bus  traffic  has  a  fixed  limit  of  1 
megabits  per  second.  Also  response  time  requirements  for  both  systems 
must  be  considered  in  designing  data  bus  protocol  and  message  handling. 

b)  Less  expandability  -  a  single  DAIS  type  data  bus  can  be  expanded  to 
accommodate  up  to  32  elements  maximum. 
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d.  Hierarchical  Data  Bus  Architecture 


The  hierarchical  concept  is  shown  in  Figure  12.  The  key  difference  between 
this  arrangement  and  the  previous  two  concepts  is  that  the  power  system 
processor  is  connected  between  a  separate  avionics  data  bus  and  power  system 
data  bus.  The  power  system  processor  is  a  remote  terminal  on  the  avionics  bus 
but  a  bus  controller  on  the  power  system  data  bus.  The  number  of  RTs,  ELMCs, 
and  GCUs  needed  in  order  to  accommodate  the  power  system  control  requirements 
is  the  same  as  in  previously  discussed  architectures.  The  key  advantages  of 
this  approach  are: 

a)  Less  bus  loading  -  because  avionics  data  can  be  obtained  from  a 
separate  bus,  the  traffic  on  the  power  data  bus  is  reduced. 

b)  Greater  expandability  -  the  hierarchical  data  bus  architecture  offers 
almost  unlimited  growth  potential  due  to  the  ability  to  cascade  any 
number  of  data  buses  each  communicating  with  the  next  via  an  interbus 
processor. 

c)  Independence  of  avionics  and  power  system  -  software  development  can 
progress  more  independently  for  the  avionics  and  power  system  since 
the  need  to  coordinate  response  time  requirements  is  almost  entirely 
eliminated. 

The  major  disadvantages  of  this  concept  are: 

a)  Immature  software/^ardware:  both  the  interbus  processor  and  its 
executive  software  for  interfacing  to  two  data  buses  is  still  in 
development. 

b)  Added  weight  -  more  bus  interface  circuitry  and  power  supplies  are 
necessary  for  multiple  1553B  data  buses  than  in  an  integrated  approach 

c)  Higher  executive  overhead  -  a  single  power  system  processor  configured 
to  be  both  an  RT  on  the  avionics  bus  and  the  bus  controller  on  the 
power  system  data  bus  incurs  enormous  software  overhead. 

2.  SELECTED  CONCEPT 

Based  on  the  foreqoing,  an  integrated  avionics  and  power  system  architecture 
using  a  single  data  bus  system  is  the  selected  concept  to  manage  and  control 
an  electrical  system  for  a  light  tactical  two-engined  fighter  aircraft  with 
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Figure  12.  Hierarchical  Architecture 


multimission  capability.  The  system  consists  of  separate  avionics  and  power 
system  processors,  5  ELMCs,  and  3  RTs  (for  the  power  system).  The  avionics 
processor  handles  the  system  overhead  and  perfor  ;s  the  bus  controller 
functions. 

The  electrical  system  consists  of  two  60  KVA  engine-driven  generators,  one  20 
KVA  auxiliary  generator,  three  100  A  28  vnc  TP.Us  and  500  SSPCs.  Software  for 
this  system  uses  the  JOVIAL  J73  higher  order  language. 

The  selection  of  the  integrated  architecture  is  based  on  the  assumption  that 
avionics  bus  loading  including  overhead  does  not  exceed  36%  of  total  capacity 
of  an  MIL-STD-1553B  data  bus.  Also  that  the  total  number  of  avionics  and 
power  system  elements  attached  to  the  data  bus  does  not  exceed  32. 
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SECTION  IV 


SYSTEM  HARDWARE  AND  SOFTWARE  DEVELOPMENT 

A  detailed  design  was  performed  on  the  Advanced  Aircraft  Electrical  System. 

The  resuls  of  the  design  are  hardware  and  software  specifications  for  the 
components  of  the  system.  In  addition,  a  system  level  specification  was 
prepared. 

1.  SYSTEM  SPECIFICATION 

The  aAES  configuration  is  shown  in  Figure  13.  The  unique  feature  of  the  AAES 
is  the  integrated  data  bus  architecture  of  the  control  subsystem.  As  shown  in 
Figure  14,  elements  of  the  AAES  and  of  the  avionics  system  are  integrated  on 
the  same  dual  redundant  data  bus. 

The  Advanced  Aircraft  Electrical  System  (AAES)  is  subdivided  into  three 
subsystems,  power  generation,  power  distribution,  and  control.  The  power 
generation  subsystem  includes  the  primary  and  secondary  power  sources.  This 
includes  two  engine  driven  generators,  an  auxiliary  power  unit  (APU) 
generator,  and  provisions  for  external  power  plication.  In  addition  DC 
power  is  provided  by  three  transformer  rectifier  units  (TRU)  and  these  are 
backed  up  by  a  battery.  The  power  distribution  subsystem  distributes  power 
from  the  main  power  buses,  AC  and  DC,  to  distributed  load  centers  called 
electrical  load  management  centers  (ELMC).  Within  the  ELMCs  are  solid  state 
power  controllers  (SSPC)  which  control  power  to  the  individual  aircraft 
loads.  The  control  subsystem  consists  of  a  dual  redundant  multiplex  data  bus 
(MIL-STD-1553B) ,  16-bit  processors  (MIL-STD-1750) ,  controls  and  displays,  and 
remote  terminals  (RT).  The  control  subsystem  incorporates  DAIS  hardware  and 
software.  The  control  subsystem  provides  for  automatic  system  operation  of 
the  AAES  under  normal  and  abnormal  operating  conditions. 

a.  Power  Generation  Subsystem 

The  power  generation  subsystem  is  shown  in  Figure  15.  Primary  power  shall  be 
provided  from  two  engine  driven  variable  speed  constant  frequency  (VSCF) 
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Figure  15.  Power  Generation  Subsystem 


generators.  These  generators  shall  operate  in  the  isolated  mode  only.  An 
inflight  operable  APU  generator  shall  be  provided  for  emergency  operation  and 
also  for  ground  power  operation.  An  external  power  receptacle  shal i  be 
provided  for  ground  operation.  None  of  the  AC  power  sources  shall  be 
paralle’ed.  The  generator  circuit  breakers  ( GCB )  are  used  to  control  power  to 
the  main  AC  bus  from  the  VSCF  generator.  The  GCB  is  under  control  of  the  VSCF 
generator  control  system.  The  bus  tie  breakers  (BTB)  allow  the  main  AC  buses 
to  be  paralleled  during  single  generator  operation,  APU  generator  operation, 
and  external  power  operation.  In  addition  to  allowing  cross  powering  of  the 
main  AC  buses  the  BTBs  provide  overcurrent  protection.  The  BTB  is  controlled 
by  the  circuit  shown  in  Figure  16.  The  auxiliary  power  contactor  (APC) 
controls  application  of  power  to  the  AC  tie  bus  from  the  APU  generator.  The 
external  power  contactor  (EPC)  controls  application  of  power  to  the  AC  tie 
from  the  external  power  source.  In  addition,  the  EPC  provides  overcurrent 
protection  for  the  external  power  source.  The  control  circuits  for  the  APC 
and  the  EPC  are  shown  in  Figure  16. 

Three  TRUs  provide  DC  power  te  the  AAES.  Each  TRU  provides  power  to  its  own 
isolated  DC  bus  as  shown  in  figure  15.  TRU  1  and  TRU  2  receive  AC  power  from 
AC  Bus  1  and  AC  Bus  2  respectively.  TRU  3  receives  power  from  either  AC  Bus  1 
and  AC  Bus  2  through  the  relay  configuration  shown  in  Figure  15.  DC  Bus  3  is 
paralleled  through  a  diode  to  the  Battery  Bus.  The  Battery  Bus  is  connected 
to  the  Hot  Battery  Bus  through  a  relay  controlled  by  a  cockpit  mounted 
switch.  A  battery  is  connected  directly  to  the  Hot  Battery  Bus.  The  battery 
is  charged  by  TRU  3. 

b.  Power  Distribution  Subsystem 

The  power  distribution  subsystem  distributes  power  from  the  main  AC  and  DC 
power  buses  to  distributed  load  centers  called  electrical  load  management 
centers  (ELMC).  Within  the  ELMCs  are  solid  state  power  controllers  (SSPC) 
which  control  power  (and  also  provide  overcurrent  protection)  to  the 
individual  aircraft  loads.  The  power  flow  is  shown  in  Figure  17.  The 
electromechanical  power  controller  (EMPC)  shall  provide  fault  protection  for 
the  feeder  to  the  ELMC.  The  EMPC  shall  also  control  power  to  loads  connected 
directly  to  the  main  power  buses.  The  subsystem  shall  have  7  ELMCs  and  500 
SSPCs. 
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Within  the  ELMC  are  a  three  phase  AC  bus,  a  DC  bus,  and  a  flight  critical  DC 
bus.  As  shown  in  Figure  13,  each  bus  is  supplied  from  two  sources  of  power. 
One  of  the  power  sources  for  the  fliqht  critical  DC  bus  is  the  battery  bus. 
This  battery  bus  connection  makes  this  bus  an  uninterruptible  power  bus  for 
powering  flight  control  computers. 

The  feeders  from  the  main  AC  and  DC  buses  arc  protected  from  overcurrent  by 
EMPCs.  The  EMPCs  also  provide  on/off  control.  The  EMPCs  are  controlled  by 
the  control  subsystem  through  RTs.  During  system  operation,  these  EMPCs 
remain  closed. 

c.  Control  Subsystem 

The  control  subsystem  is  shown  in  Figure  18.  The  control  subsystem  provides 
for  automatic  system  operation  of  the  AAES  under  normal  and  abnormal  operating 
conditions.  The  electrical  system  control  is  integrated  with  the  avionics 
system  in  that  both  systems  share  a  common  1553B  multiple  data  bus.  The  bus 
control  function  resides  in  the  avionics  system  processor;  however,  control  of 
the  AAES  resides  in  the  power  system  processor.  The  control  subsystem 
incorporates  the  DAIS  architecture  and  the  DAIS  core  elements  which  include 
DAIS  processors,  remote  terminals,  and  data  bus.  In  addition,  the  control 
subsystem  shall  include  a  controls  and  display  unit,  mass  memory  unit,  and  a 
bus  monitor. 

Dual  redundant  power  system  processors  shall  be  used  to  control  the  AAES.  The 
power  system  processors  (PSP)  shall  use  two  discrete  uni -directional  control 
lines  to  transfer  control  between  the  two  PSPs. 

In  the  control  subsystem,  centralized  single  point  data  bus  control  shall  be 
performed  by  only  one  processor  which  is  designated  the  master.  In  this 
control  mode,  the  master  which  is  the  avionics  processor,  issues  commands  to 
other  devices  on  the  data  bus,  participates  in  data  transfers  on  the  bus  if 
required,  checks  status  response  from  the  addressed  devices  and  interprets 
anomalies  for  all  bus  traffic.  Remote  mode  is  the  operational  state  assigned 
to  those  processors  which  are  not  directed  to  be  master,  including  the  power 
system  processor.  Remote  mode  functions  include  monitoring  of  the  multiplex 
data  bus  for  commands  directed  to  that  address,  responding  with  an  appropriate 
status  word,  and  sending  or  receiving  bus  data. 
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In  the  AAES  laboratory  simulator,  the  a/ionics  system  processor  (and  bus 
controller)  shall  be  simulated. 

d.  Real  Time  System  Software 

The  AAES  simulator  requires  several  major  software  modules.  These  modules 
include  operating  system  executives  to  control  and  synchronize  operations  in 
the  PSP  and  ELMCs.  In  addition,  the  PSP  and  ELMCs  each  contain  applications 
software  for  performing  their  respective  functions.  Software  modules  are  also 
required  for  the  avionics  simulator  and  the  bus  monitor,  respectively. 

e.  Non-Real  Time  Support  Software 

Support  software  modules  are  required  for  the  AAES  simulator.  These  non-real 
time  software  modules  are  the  Jovial  J73  compiler,  the  Avionics  Lab  Assembler 
Program  (ALAP),  and  the  partitioning  Analyzing  and  Linkage  Editing  Facility 
(PALEFAC) . 

(1)  Jovial  J73  Compiler 

The  AAES  software  will  for  the  most  part  be  compiled  with  the  J73  compiler. 
Furthermore,  those  sections  of  code  which  are  not  written  in  J73  must  be 
consistent  with  the  linkages  used  by  that  compiler.  The  JOVIAL  compiler  is  a 
non-real  time  program  which  translates  high-order-language  statements  ( J 73 
source  code)  as  specified  in  MIL-STD-1589A  into  software  object  modules 
(mission  software  and  support  software)  which  can  be  loaded  and  executed  on 
specified  target  computers  (e.g.  DAIS  processors,  DEC-10  computer). 

The  system  programmer  will  generate  the  J73  source  input  and  compool  input 
files  using  the  JOVIAL  J73  User’s  Guide  MA  224  200.  The  programmer  will  then 
compile  the  source  programs  using  the  J73  compiler  which  shall  produce  source 
listings,  cross  references,  object  listings,  and  the  relocatable  object  files 
for  the  selected  target  computer. 

The  output  of  the  J73  compilation  shall  be  relocatable  module  files.  In  order 
to  execute  the  program  on  the  DEC-10,  it  shall  be  converted  from  relocatable 
file  to  core  image  form  using  the  DEC-10  (LINK-10)  linker  loader.  In  order  to 
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execute  the  program  on  the  DAIS  processor,  it  siall  also  be  converted  to  core 
image  form  using  the  DAIS  Processor  linker  loader. 

(2)  ALAP  Assembler 

Machine  dependent  features  of  the  AAtS  software  are  translated  by  the  ALAP 
assembler,  described  in  DAIS  Assembler  User's  Reference  Manual,  SA  206201. 

(3)  Partitioning  Analyzing  and  Linkage  Editing  Facility  {PALEFAC) 

PALEFAC  is  a  non-real  time  support  software  tool  for  use  by  the  system 
designer  and  application  programmer  to: 

(a)  Build  the  data  tables  for  the  DAIS  loader  and  master  executives. 

(b)  Provide  bus  analysis  and  module  partitioning  information. 

(c)  Produce  the  executive  tables  in  J73  source  code. 

(d)  Generate  linker  command  files  for  each  DAIS  processor  for  the 
DEC-10  Linker  or  HBC  Linker. 

PALEFAC  is  used  as  a  stand  alone  tool  and  consists  of  three  basic  programs  as 
shown  in  Figure  19.  PALEFAC  pre-processor,  PALEFAC  main  program,  and  PALEFAC 
module  input  (PMI)  decoder. 

PALEFAC  will  oe  used  to  build  the  mission  software  load  modules  for  each  of 
the  DAIS  processors.  Inputs  to  PALEFAC  are  the  application  software  modules 
including  the  executive  service  requests  generated  by  the  application 
programmer  in  J73  source  code.  The  pre-processor  shall  read  each  application 
module  and  create  a  record  for  each  application  module  in  the  PMI  file. 

The  system  design  will  prepare  PALEFAC  Global  Input  (PGI)  file  based  upon  the 
specific  system  configuration,  partitioning  of  application  tasks  to  each 
processor,  and  bus  messages  to  each  terminal.  This  shall  include: 

(a)  Bus  Messages 

o  To/from  data  block  name  or  Terminal  Address/Subaddress 
o  Cycle  (period  and  phase)  for  synchronous  transmissions 
o  Activity  request  identificaion  for  asynchronous  transmission 
o  Word  count 
o  Class  of  retry 
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Figure  19.  PALEFAC  Structure 


(b)  List  of  all  tasks  or  modules  for  each  processor 

(c)  Override  directives 

(d)  Number  of  processors  in  the  system  configuration  and  address  of  each 
terminal 

The  system  designer  will  also  generate  the  PALEFAC  Auxiliary  File  (PAL)  for 
common  subroutines  (comsubs)  and  common  communication  data  blocks  (compools). 

The  PALEFaC  main  program  shall  build  the  executive  tables  and  linker  command 
files  based  upon  the  system  designer  specified  configuration.  The  output  of 
PALEFAC  shall  be  the  PALEFAC  mission  files  ( PMD ) ,  PALEFAC  Partitioning 
Information  Files  (PPI),  and  text  output  files  shown  in  Figure  19.  The  PMD 
files  shall  contain  all  the  executive  tables  including  the  bus  control  tables 
in  J73  source  code.  The  PPI  files  shall  contain  the  linker  commands  for  each 
processor  and  specify  all  the  mission  software  modules  (e.g.  executive 
modules,  application  tasks,  comsubs,  and  executive  tables)  in  oraer  for  the 
linker  to  produce  the  load  modules  for  each  processor. 

PALEFAC  shall  also  produce  text  output  files  listing  all  the  PALEFAC  input 
files,  the  output  files,  and  error  messages. 

2.  HARDWARE  SPECIFICATIONS 


The  electrical  control  system  consists  of  a  distributed  network  of  processors, 
controllers,  and  terminals  that  monitor  the  electrical  power  system  and  exert 
control  functions  over  it.  The  various  elements  of  the  electrical  control 
system  communicate  with  each  other  via  messages  transferred  on  a  standard  DAIS 
1553B  multiplex  data  bus.  Control  and  synchronization  of  the  data  bus  is 
performed  by  the  avionics  processor.  All  electrical  control  system  elements 
perform  as  remote  terminals  in  relation  to  the  avionics  processor.  Those 
elements  that  make  up  the  electrical  control  system  are  the  PSP,  7  ERTs,  5 
DAIS  RTs,  2  GCUs,  avionics  controls  and  displays,  and  a  DAIS  mass  memory  unit. 
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a.  Pow'  r  System  Processor 


The  PSP  provides  overall  control  of  the  electrical  control  system.  Electrical 
system  status  information  is  provided  to  the  PSP  by  other  elements  in  the 
electrical  control  system.  Avionics  controls  provide  updated  control  and 
flight  mod'  information  whenever  this  information  changes.  The  PSP  uses  this 
information  to  calculate  load  management  priority  1evels,  power  generation  and 
distribution  system  configuration  requirements,  and  electrical  power  request 
equation  solutions.  The  PSP  also  controls  the  electrical  control  system 
during  system  startup  and  shutdown  operations  as  well  as  during  normal 
operations. 

The  PS?  is  an  AN/AYK-15A  digital  processor  with  128K  16  bit  words  of  memory. 
This  processor  is  described  in  DAIS  specification  SA  421205  (Reference  9). 

The  primary  function  of  the  PSP  is  to  provide  control  and  management  of  the 
aircraft  electrical  system.  To  accomplish  this,  the  PSP  must  perform  the 
executive  and  applications  software  functions  as  described  in  paragraph  4  of 
this  section. 

b.  Electrical  Load  Management  Center 

The  ELMCs  provide  control  and  management  of  the  electrical  power  distributed 
to  the  loads  connected  to  them.  Each  ELMC  contains  72  SSPCs  from  which  it 
receives  status  information  and  sends  control  information.  The  ELMCs 
interface  with  the  PSP,  via  the  MIL-STD-1553B  data  bus.  Each  ELMC  contains  an 
imbedded  electrical  remote  terminal  (ERT).  Control  of  the  ►IMC,  its  I/O 
subsystems,  and  bus  interface  is  handled  by  a  microprocessor  within  the  ERT. 
The  ELMC  design  is  modular  to  allow  signal  w  idling  to  be  incrementally 
expanded  or  contracted  in  order  to  accommodate  the  requirements  of  a 
particular  load  configuration.  Figure  20  is  an  ELMC  functional  diagram.  The 
main  purpose  of  the  ELMCs  is  to  provide  electrical  power  as  needed  to  aircraft 
subsystems,  consistent  with  the  present  electrical  load  management  priority 
level.  This  purpose  is  achieved  by  accomplishing  several  functions  including 
power  distribution  center  control  and  monitoring,  SSPC  control  and  monitoring, 
aircraft  discrete  and  analog  signal  monitoring,  ERT  software  computations,  and 
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ELMC 
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Figure  20.  ELMC  Functional  Block  Diagram 


(1)  Power  Distribution  Center 

The  power  distribution  center  as  depicted  in  Figure  21  provides  automatic 
selection  of  power  sources  for  the  ELMC  AC  and  DC  buses.  All  power  buses 
within  the  ELMC  have  two  sources  of  power,  one  of  which  is  designated  the 
primary  source  and  the  other  is  designated  the  secondary  source.  Under  normal 
operating  conditions,  power  to  each  bus  is  supplied  by  the  primary  source.  If 
the  primary  source  fails,  power  is  automatically  provided  by  the  secondary 
source.  Precautions  will  be  taken  to  insure  that  two  sources  are  not 
connected  to  a  particular  bus  at  the  same  time.  Selection  of  power  sources 
can  also  be  done  by  control  of  the  ERT  computer.  In  the  case  of  the  flight 
critical  bus,  the  primary  power  source  is  the  DC  bus  which  is  powered  by 
either  its  own  primary  or  secondary  source,  and  the  secondary  power  source  is 
a  battery.  This  battery  is  diode-paralleled  with  the  primary  source  to  insure 
that  the  battery  is  isolated  from  faults  in  the  main  DC  system. 

(2)  SSPC  Control  and  Monitoring 

The  SSPC  control  unit  receives  control  inputs  *rom  the  ERT,  outputs  SSPC 
status  to  the  ERT,  and  controls  the  power  suoplied  to  various  aircraft  loads 
with  SSPCs-  Each  SSPC  is  controlled  by  a  single  ON/OFF  signal  and  provides  a 
TRIP  signal  and  an  ON/OFF  status  signal. 

c.  Electrical  Remote  Terminal 

The  Electrical  Remote  Terminal  (ERT)  provides  the  mechanism  for  interfacing 
solid  state  power  controllers  (SSPCs)  to  a  MIL-STD-1553B  data  bus  within  the 
Electrical  Load  Management  Center  (ELMC).  In  addition  to  the  ERT  interfaces 
discrete  and  analog  sensor  signals  to  the  MIL-STD-1553B  data  bus.  Control  of 
the  ERT,  its  I/O,  and  bus  interface  shall  be  handled  by  an  embedded 
microprocessor.  The  ERT  contains  its  own  power  supply.  The  EPT  design  is 
modular  and  flexible  to  allow  signal  handling  and  power  control  to  be 
incrementally  expanded  or  contracted  in  order  to  satisfy  the  requirements  of  a 
particular  aircraft  physical  location. 

The  ERT  consists  of  the  following  major  components,  arranged  as  shown  in 
Figure  22: 
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Distribution  Center 


Figure  22.  ERT  Functional  Block  Diagram 


a.  Dual  processors 

b.  Dual  memory 

c.  Dual  Bus  Interface  Units  (BIU) 

d.  Dual  I/O  decode  control  units 

e.  Dual  logic  power  supplies 

(1)  MIL-STD-1553B  Data  Bus  Interface 

The  electrical  characteristics  and  data  transfer  characteristics  of  the  bus 
interface-  are  specified  in  MIL-?TD-1553B.  MIL-STD-1553B  protocol  and  system 
control  options  shall  be  per  SA  321200  unless  othe»wise  specified  in  this 
document.  The  Bus  Interface  Unit  (BIU)  shall  be  the  device  that  interfaces 
the  ERT  to  the  MIL-STD-1553B  data  bus.  There  shall  be  two  such  BIUs  in  the 
ERT.  Each  BIU  shall  be  capable  of  interfacing  with  a  single  MIL-STD-1553B 
data  bus  or  an  active/standby  data  bus  pair. 

(2)  I/O  Bus  Interface 

The  I/O  bus  shall  interface  the  ERT  with  the  ElMC  interface  modules.  The  dual 
I/O  decode  control  units  in  the  ERT  shall  control  the  I/O  bus.  The  I/O  decode 
control  unit  associated  with  the  active  ERT  processor  shall  be  in  control  of 
the  I/O  bus.  I/O  bus  signal  set  shall  consist  oi  address,  data  and  control 
lines  as  shown  in  Figure  22. 

(3)  Electrical  Power  Interface 

The  ERT  shall  derive  its  power  and  reference  voltages  from  the  air  vehicle 
power  system  or  laboratory  power  system  depending  on  installation.  Primary 
power  shall  be  derived  from  the  115  VAC,  400  Hz  air  vehicle  power  system.  Tile 
ERT  shall  perform  all  its  normal  functions  when  supplied  w;th  115  VAC,  ^00  Hz, 
3-phase  power  in  accordance  with  MIL-STD-704C. 

(4)  ERT  Software  Computations 

ERT  software  computations  include  load  priority  handling,  power  control 
equation  solving,  power  system  status  equation  solving,  and  1553B  bus 
communications.  These  functions  are  discussed  under  ERT  software  functions. 
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(5)  Built  In  Test 


BIT  as  performed  by  the  ERT  includes  tests  of  SSPCs  and  interface  modules, 
d.  Solid  State  Controller 

Solid  state  power  controllers  (SSPC)  are  used  to  control  power  to  the  aircraft 
loads  and  to  protect  the  load  feeders  from  faults.  The  SSPCs  are  mounted  on 
circuit  boards.  Then  circuit  boards  are  contained  in  the  ELMC.  The  circuit 
board  and  the  SSPC  interface  are  shown  in  Figure  23. 

The  SSPCs  are  controlled  by  the  ERT.  Three  discrete  signals  are  transferred 
between  the  SSPCs  and  the  ERT.  These  signals  are  listed  below. 

SSPC  Discrete  Signals 


input:  Control,  ON/OFF 

outputs:  Trip  (overcurrent 
Status  (on/off) 

There  shall  be  up  to  72  SSPCs  per  ELMC.  The  distribution  of  SSPCs  in  the 
system  and  in  each  ELMC  is  shown  in  Table  4. 

e.  Electromechanical  Power  Controller 

Electromechanical  power  controllers  (EMPC)  are  used  to  control  power  to  loads 
which  are  connected  to  the  main  AC  or  DC  buses.  In  addition,  the  EMPCs 
provide  fault  protection  to  the  load  feeders.  The  EMPCs  are  also  used  to 
protect  the  AC  and  DC  load  feeders  to  the  ELMCs.  The  EMPCs  provide 
overcurrent  protection  as  well  as  on/off  control.  The  EMPC  requirement  for 
the  system  is  shown  in  Table  5. 

The  EMPCs  are  controlled  by  the  RTs.  Three  discrete  signals  are  transferred 
between  the  EMPCs  and  the  RT.  These  signals  are  listed  below. 
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SSPC 


TYPICAL  UNIT 


115  VAC/28  DVC  t 


CONTROL 

STATUS 
TRIP/BIT 
SIG.  GNO. 


PWRIN 

OUT  IN 
NEUTRAL 


Figure  23.  SSPC  Circuit  Card 
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TABLE  4  DISTRIBUTION  OF  SSPCs  PER  ELMC 


115  Volt  AC,  400  Hz,  SSPC  Distribution 


size 

%  total 

qty  system 

qty/ELMC 

connected  load 

2A 

31.5 

158 

23 

46  A 

3A 

8.5 

43 

6 

18A 

5A 

7 

35 

5 

25A 

7.5A 

3 

15 

2 

15A 

104  Amps 

28  Volt  DC  SSPC 

Distribution 

size 

%  total 

qty  system 

qty/ELMC 

connected  load 

2A 

37 

185 

26 

52A 

3A 

6.5 

33 

5 

15A 

5A 

2 

10 

2 

10A 

7.5A 

2 

10 

2 

15A 

10A 

1.5 

8 

1 

10A 

15A 

0.5 

3 

0.4 

OA 

20A 

0.5 

3 

0.4 

OA 

102  Amps 


Notes: 

1)  system  count  rounded  to  nearest  integer  for  500  SSPCr. 

2)  qty/ELMC  rounded  to  nearest  integer  for  7  ELMCs. 

3)  mission  profiles  shown  lower  actual  than  connected  loads. 
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TABLE  5  EMPC  REQUIREMENTS 


115  VAC,  400  Hz,  Three  Phase 

APPLICATION 

SIZE 

QUANTITY 

Power  Distribution 

To  ELMCs 

30  A 

14 

Fuel  Pumps 

15  A 

2 

TRUs 

15  A 

4 

Power  System  Processors 

5  A 

4 

RTs 

5  A 

5 

28  VDC 

APPLICATION 

SIZE 

QUANTITY 

Power  Distribution 

50  A 

14 

To  ELMCs 

10  A 

7 
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EMPC  Discrete  Signals 


input:  Control,  ON/OFF 

outputs:  Trip  'cvercurrent) 
Status  U  off) 


3.  SOFTWARE  SPECIFICATIONS 


The  electrical  control  system  requires  software  to  perform  the  computational 
functions  of  the  PSP  and  ERIs.  The  PSP  and  each  of  the  ERTs  require  both  a 
DAIS  type  of  executive  software  and  applications  software  designed  bo  perform 
the  appropriate  applications  functions  for  each  processor.  The  executive 
software  in  each  processor  provides  local  control  of  the  processor  execution 
process  and  also  provides  for  communications  with  the  data  bus. 

a.  Pow,.*  Sy<-„em  Processor  Executive 

The  purpose  of  the  PSP  Executive  is  to  provide  a  rigid  interface  between  the 
hardware  composing  the  DAIS  federated  system  and  the  applications  software 
which  executes  in  the  PSP.  This  irterface  permits  applications  software  to  be 
developed  without  any  knowledge  of  the  information  transfer  system  hardware  or 
its  operation.  In  a  similar  fashion,  many  hardware  modi f1' rations  can  be  made 
without  any  affect  on  the  applications  software,  since  references  to  time  or 
to  remote  terminals  are  made  on  a  logical  level.  Finally,  the  PSP  executive 
allows  PSP  applications  software  to  execute  efficiently. 

The  PSP  executive  software  is  a  local  executive  which  controls  operations 
peculiar  to  the  PSP,  including  control  of  the  applications  software  within  the 
processor  and  local  participation  in  the  I/O  processes.  The  architecture  of 
the  PSP  executive  system  implies  a  separation  of  functional  components,  the 
control  of  one  component  over  another,  and  the  dependence  of  one  component  on 
another.  The  PSP  executive  system  architecture  is  shown  in  Figure  24 
depicting  the  separation  of  hardware  and  software  functions.  The  applications 
software  is  functionally  isolated  from  the  hardw^e  by  the  executive  software 
just  as  the  electrical  control  subsystems  are  isolated  from  the  computers  by 
the  remote  terminals  and  data  bus. 
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POWER  SYSTEM  PROCESSOR 


APPLICATION  SOFTWARE 


PSP  EXECUTIVE 


PROCESSOR  AND  MEMORY 
HARDWARE 


BUS  INTERFACE 


1553B  DATA  BUS 


Figure  24.  PSP  System  Architecture  with  PSP  Executive 
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The  PSP  executive  is  a  real  time  system,  in  which  the  activities  of  the 
applications  software  are  coordinated  with  the  passage  of  real  time  in  the 
outer  world.  The  minimum  granularity  of  time  to  which  coordination  occurs  is 
known  as  the  minor  cycle.  It  is  possible  to  specify  or  determine  the  time  of 
an  action  within  one  minor  cycle,  but  not  to  a  fraction  of  a  minor  cycle. 

Thus,  the  I/O  interactions  and  task  interactions  may  occur,  may  be  known,  and 
may  be  controlled  within  the  framework  of  the  minor  cycle  time  granularity. 
This  timing  is  a  requirement  for  I/O  control,  synchronizaion  and  executive 
process  handling.  In  addition,  the  PSP  executive  provides  the  interface 
between  the  applications  functions  and  the  bus  control  functions  which  reside 
in  the  avionics  processor. 

b.  Power  Systpm  Processor  Applications 

The  PSP  applications  software  resides  in  the  PSP  and  executes  under  control  of 
the  PSP  executive.  A  functional  block  diagram  of  the  PSP  applications 
software  is  presented  in  Figure  25.  As  shown  in  Figure  25.  this  software 
consists  of  a  large  number  of  modules  called  tasks,  routines  and  comsubs. 

Each  software  module  performs  a  unique  function.  The  major  functions  are 
performed  by  tasks,  and  lesser  functions  are  performed  by  subordinate  tasks, 
and  routines  that  are  called  by  tasks.  Comsubs  are  routines  that  perform 
functions  which  are  needed  by  more  than  one  task  or  routine. 

The  purpose  of  the  PSP  applications  software  is  to  provide  control  of  the 
power  distributed  to  aircraft  loads  in  order  to  insure  that  maximum  available 
power  is  delivered  to  the  loads,  depending  on  aircraft  mission  and  flight 
phase,  and  the  condition  of  the  power  generation  subsystem.  In  order  to 
accomplish  its  purpose,  the  PSP  applications  software  must  monitor  and  control 
the  power  generator  subsystem  in  order  to  maintain  maximum  available  power. 
This  is  done  by  switching  ELMCs  from  an  overloaded  generator  to  an 
underutilized  generator  whenever  possible.  If  this  fails,  then,  this  software 
must  compute  a  new  load  management  priority  level,  consistent  with  the  present 
aircraft  flight  phase,  and  transmit  this  load  priority  level  to  all  ELMCs  so 
that  load  management  can  be  performed.  This  software  is  also  responsible  for 
solving  power  request  equations  resulting  from  requests  received  from  aircraft 
controls.  The  Dower  requests  that  result  from  solving  these  equations  are 
then  transmitted  to  the  appropriate  ELMCs  where  load  management  is  performed. 
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Applications  Software  Modules  Diagram 


In  addition,  the  PSP  applications  saftvrre  gathers  and  logs  electrical  control 
system  error  data,  and  transmits  electrical  system  displays  data  to  the 
avionics  processor.  Finally,  this  software  is  responsible  for  startup  and 
shutdown  of  the  electrical  control  subsystem. 

c.  Electrical  Remote  Terminal  Executive 

The  purpose  of  the  ERT  Executive  is  to  provicj  a  rigid  interface  between  the 
hardware  composing  the  DAIS  federated  system  and  the  applications  software 
which  executes  in  the  ERT.  This  interface  permits  applications  software  to  be 
developed  witnout  any  knowledge  of  the  information  transfer  system  hardware  or 
its  operation.  In  a  similar  fashion,  many  hardware  modifications  can  be  made 
without  any  affect  on  the  applications  software,  since  references  to  time  or 
to  remote  terminals  are  made  on  a  logical  level.  Finally,  the  ERT  executive 
allows  ERT  applications  software  to  execute  efficiently. 

The  ERT  executive  software  is  a  local  executive  which  controls  operations 
peculiar  to  the  ERT,  including  control  of  the  applications  software  within  the 
processor  and  local  participation  in  the  I/O  processes.  The  architecture  of 
the  ERT  executive  system  implies  a  separation  of  functional  components,  the 
control  of  one  component  over  another,  ar>d  the  dependence  of  one  component  on 
another.  The  EIT  executive  system  architecture  is  shown  in  Figure  26 
depicting  the  separation  of  hardware  and  software  functions.  The  applications 
software  is  functionally  isolated  from  the  hardware  by  the  executive  software. 

The  ERT  executive  is  a  realtime  system,  in  which  the  activities  of  the 
applications  software  are  coordinated  with  the  passage  of  real  time  in  the 
outer  v'.-ld.  The  minimum  granularity  of  time  to  which  coordination  occurs  is 
knt  r  as  the  minor  cycle.  It  is  possible  to  specify  or  determine  the  time  of 
an  acfciar  within  one  minor  cycle,  but  not  to  a  fraction  of  a  minor  cycle. 

Thus,  the  I/O  interactions  and  task  interactions  may  occur,  may  be  known,  and 
may  be  controlled  within  the  f  amework  of  the  minor  cycle  time  granularity. 
This  timing  is  a  requirement  for  I/O  control,  synchronization  and  executive 
process  handling.  In  addition,  the  ERT  executive  provides  the  interface 
between  the  applications  functions  and  the  bus  control  functions  which  reside 
in  the  avionics  processor. 
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Figure  26.  ERT  System  Architecture  with  ERT  Executive 
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d.  Electrical  Remote  Terminal  Applications 

The  main  purpose  of  the  ERT  applications  software  is  to  control  and  monitor 
electrical  power  that  is  distributed  to  individual  aircraft  loads  via  SSPCs. 
This  must  be  done  in  a  manner  consistent  with  the  present  load  management 
priority  level  as  determined  by  the  PSP.  A  copy  of  the  ERT  app1  cations 
software  resides  in  each  ERT  and  executes  under  control  of  the  ERT  executive 
which  also  resides  in  each  ERT.  This  software  is  table  driven.  Those  tables 
that  are  unique  to  individual  ERTs  are  loaded  from  the  DAIS  mass  memory  at 
system  initialization  time.  This  provision  allows  identical  program  code  to 
be  used  in  all  ERTs.  To  accomplish  its  purpose,  the  ERT  applications  software 
must  perform  several  different  functions.  A  diagram  showing  the  functional 
layout  of  the  ERT  applications  software  is  presented  in  Figure  27. 

The  main  functions  performed  by  the  ERT  applications  software  include  task 
sequencing,  processing  of  PSP  requests,  and  monitoring.  The  task  sequencing 
function  is  performed  by  the  master  sequencer  software  module  which  maintains 
control  over  scheduling  of  other  applications  functions.  Processing  of  PSP 
requests  includes  both  high  priority  request  processing  and  low  priority 
request  processing.  High  priority  requests  include  load  management  priority 
level  changes,  and  power  distribution  center  change  commands.  Low  priority 
PSP  requests  include  aircraft  sensor  output  data,  power  requests,  and  an 
applications  terminate  request.  The  monitoring  functions  include  gathering 
status  data  from  the  power  distribution  center,  SSPCs,  and  aircraft  sensors. 
The  status  data  is  collected  and  transmitted  to  the  PSP. 

4.  SYSTEM  DRAWINGS 


The  system  data  bus  diagram  is  shown  in  Figure  28.  The  system  data  flow  is 
shown  in  Figure  2S.  The  system  power  flow  is  shown  in  Figure  30. 


Figure  27.  ERT  Application*  Software  Structure* 


Figure  28.  System  Data  Bus  Diagram 
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SUPPORT  HARDWARE  AND  SOFTWARE  DEVELOPMENT 


1.  LABORATORY  SIMULATOR  DESIGN 

The  laboratory  simulator  includes  the  electrical  system  which  would  be 
implemented  on  an  aircraft  and  the  support  hardware  and  software  required  to 
demonstrate  the  a..anced  aircraft  electrical  system  in  a  laboratory 
demonstrator.  A  power  system  simulator  hardware  specification  has  been 
developed.  This  specification  defines  the  support  hardware  necessary  to 
demonstrate  the  advanced  aircraft  electrical  system.  The  major  hardware 
components  are  shown  in  Figure  31.  The  simulator  will  be  located  in  the  APL 
electrical  laboratory  as  shown  in  Figure  32.  The  physical  layout  of  the 
simulator  hardware  is  shown  in  Figure  33.  The  two  major  modules  are  the  test 
console,  shown  in  Figure  34  and  the  equipment  rack  shown  in  Figure  35. 

2.  SIMULATOR  HARDWARE  SPECIFICATIONS 

Laboratory  simulator  hardware  consists  of  those  hardware  elements  that  are 
needed  to  provide  simulation  and  monitoring  of  the  aircraft  electrical  system 
in  a  laboratory  environment.  Specifications  have  been  developed  for  the 
following  simulator  hardware  items:  system  test  console,  avionics  simulator, 
and  bus  monitor. 

a.  System  Test  Console 

The  system  test  console,  shown  in  Figure  34,  provides  the  operator  interface 
to  the  simulator.  The  simulator  is  run  from  the  test  console.  The  test 
console  contains  the  following: 

o  avionics  simulator  and  user  console 
o  2  power  system  processor  use*’  terminals 
o  bus  monitor 
o  cockpit  CRT  terminal 

discrete  imut/output  control  and  display  panel 


o 
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Figure  34.  System  Test  Console 


Figure  36.  Simulator  Equipment  Rack 


o  processor  and  remote  terminal  control  panel 
o  electrical  system  control  panel 
o  SSPC  status  display 
o  power  system  display 

b.  Avionics  Simulator 

The  avionics  simulator  hardware  provides  in  a  laboratory  environment,  those 
functions  that  are  provided  by  the  avionics  processor  aboard  an  actual 
aircraft.  These  functions  which  are  provided  by  the  avionics  simulator 
software  include  bus  control,  simulation  of  avionics  sensor  data,  controls  and 
displays,  and  generation  of  avionics  system  bus  traffic.  The  avionics 
simulator  includes  an  operator  console  consisting  of  a  keyboard  and  a  CRT 
display.  A  functional  block  diagram  of  the  avionics  simulator  is  presented  in 
Figure  36. 

c.  Bus  Monitor 

The  bus  monitor  observes  all  messages  transmitted  on  the  1553B  data  bus,  and 
maintains  statistics  and  error  information  regarding  these  messages.  The  bus 
monitor  includes  a  keyboard  to  allow  operator  selection  of  data  for 
observation.  Also  included  is  a  CRT  display  for  operator  viewing  of  bus 
message  statistics  and  error  data.  The  bus  monitor  is  commercially  available 
equipment  for  use  in  the  laboratory  simulator.  The  bus  monitor  contains  a 
central  processing  unit  and  support  logic  sufficient  to  support  the 
computational  tasks  of  the  bus  monitor  software. 

3.  SIMULATOR  SOFTWARE  SPECIFICATIONS 

Simulator  software  specifications  refer  to  specifications  for  software  that 
are  uted  only  in  the  laboratory  simulator,  and  are  not  intended  for  use  aboard 
an  aircraft.  Software  that  falls  into  this  category  includes  avionics 
simulator  software,  and  bus  monitor  software. 

a.  Avionics  Simulator 

The  Avionics  Simulator  software  executes  in  the  avionics  simulator  processor 
in  order  to  provide  in  the  laboratory,  those  functions  that  are  provided  by 
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Figure  36.  Avionics  Simulator  Functional  Block  Diagram 
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the  avionics  processor  aboard  an  actual  aircraft.  These  functions  include 
control  of  the  multiplex  data  bus,  interface  to  controls  and  displays,  loading 
of  the  data  bus  to  simulate  avionics  system  bus  traffic,  and  simulation  of 
avionics  sensor  data.  In  addition,  this  software  provides  the  simulator 
operator  with  an  interface  via  a  keyboard  and  a  CRT  display  in  order  to 
facilitate  operating  and  monitoring  the  laboratory  simulator.  A  functional 
block  diagram  of  this  software  is  shown  in  Figure  37. 

The  avionics  simulator  software  is  expected  to  execute  on  commercially 
available  test  hardware.  Most  likely,  this  hardware  will  be  provided  with 
executive  software  that  performs  master  initialization  and  bus  control.  In 
this  case,  these  functions  do  not  need  tc  be  developed  separately  as  part  of 
the  avionics  simulator  software. 

b.  Bus  Monitor 

The  bus  monitor  software  executes  in  the  bus  monitor  which  is  part  of  the 
Laboratory  Simulator.  The  purpose  of  the  bus  monitor  is  to  verify  the 
validity  of  data  bus  messages  in  order  to  facilitate  system  debug  and 
checkout,  and  to  insure  successful  operation  of  the  electrical  control 
subsystem.  In  order  to  perform  these  functions,  the  bus  software  provides 
data  snapshots  and  error  trapping  of  messages  transmitted  on  the  data  bus. 

4.  TEST  plans  and  procedures 

A  demonstration  plan,  entitled  "General  Test  Plan/Procedures  Initial 
Demonstration  °lan,"  was  developed  for  the  advanced  electrical  power  system 
(AEPS)  simulator.  The  objective  of  the  plan  is  to  evaluate  the  capability  of 
the  AEPS  simulator  to  meet  the  requirements  and  demonstrate  the  flexibility 
for  change  of  the  power  system  control  equations  and  avionics  data  bus  loading. 

5.  SAFETY  ANALYSIS 

An  Operating  and  Support  Hazard  Analysis  (04SHA)  was  prepared  for  the  AAES. 

The  analysis  was  prepared  in  accordance  with  the  provisions  of  MIL-STD-882A, 
System  Safety  Program  Requirements.  The  purpose  of  the  O&SHA  is  to  ensure 
that  written  procedures  for  man/machine  operations  do  not  contain  any  inherent 
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Figure  37.  Avionics  Simulator  Software  Functional  Block  Diagram 


hazards  which  could  result  in  personnel  injury  and/or  equipment  damage.  The 
hazard  analysis  identifies  the  hazards  inherent  in  the  procedures,  the  level 
of  risk  associated  with  each  hazard,  and  the  procedural  (or  hardware)  features 
which  will  be  implemented  to  eliminate  or  control  the  identified  hazards. 

6.  RELIABILITY  AND  MAINTAINABILITY 

a.  Reliablity  Evaluation 

An  assessment  of  the  reliability  of  the  Advanced  Electrical  System  Control 
Technology  Demonstrator  was  conducted.  Three  parameters  were  used  for  the 
analysis.  These  are  the  probability  of  not  losing  AC  power,  DC  power  and  FC 
DC  power  to  a  selected  load  during  a  2.5  hour  duration  mission.  Figures  38, 

39  and  40  are  fault  trees  for  loss  of  AC  power,  loss  of  DC  power  and  loss  of 
FC  DC  power  respectively.  The  fault  trees  were  developed  down  to  the 
individual  failure  event  that  contributed  to  the  top  event.  Failure  rates 
used  as  inputs  to  the  fault  trees  were  derived  from  experience,  available  data 
and  military  handbooks.  The  computed  reliabilities  and  unreliabilities  for 
each  power  system  are  as  follows: 


Rel i abi 1 i ty 

Unreliability 

AC  Power 

.9999671 

3. 286X10* 5 

DC  Power 

.9999668 

3.317X10*5 

FC  DC  Power 

.9999820 

1.796X10*5 

b.  Maintainability  Evaluation 

The  technology  demonstrator  does  not  integrate  the  system  into  an  actual 
airframe;  therefore,  a  comprehensive  maintainbility  analysis  and  prediction  is 
not  possible  due  to  its  dependency  on  details  of  equipment  installation.  The 
system  does,  however,  have  the  potential  of  being  easily  maintained  because  of 
the  modular  nature  of  the  system,  the  ease  of  fault  isolation  afforded  by  each 
LRU  having  BIT,  and  the  capability  of  communicating  failure  conditions  to  the 
operator/maintenance  technician  via  the  data  bus. 


ire  38.  AC  Power  Loss 


Figure  40.  FC  DC  Power  Low  Fault  Tree 


SECTION  VI 


MULTIPLE  DATA  BUS  ARCHITECTURE  INVESTIGATIONS 


In  Phase  I  of  this  program  three  conceptual  designs  were  examined.  The 
baseline  concept  was  a  dedicated  electric  data  bus  system  which  would  be 
operated  independently  of  the  avionics  data  bus  system.  The  other  two  systems 
were  the  integrated  avionics/electrical  data  bus  system,  which  used  the  same 
data  bus  for  both  the  avionics  and  electrical  information  transfer;  and  a 
multiple  data  bus  architecture  which  provided  a  data  bus  for  avionics  and 
another  for  the  electrical  system  but  tied  together  by  some  interbus 
connection  device  which  would  allow  sharing  of  common  sensor  data,  controls 
and  display,  etc.  A  trade  study  performed  in  Phase  I  of  this  program 
indicated  that  for  a  two  engine  fighter  aircraft  the  integrated  system  would 
meet  the  requirements.  According  to  the  ground  rules  established,  the 
integrated  avionics/electrical  power  system  architecture  was  selected  with  the 
concurrence  of  the  AFWAL  Aero  Propulsion  Laboratory  Project  Engineer.  At  the 
Phase  I  interim  program  review  discussion  of  the  preliminary  design,  it  was 
determined  that  the  thrust  of  future  avionics  programs  such  as  the  PAVE  PILLAR 
program  would  consider  tne  use  of  multiple  data  bus  architectures  in  either 
hierarchical  or  parallel  configurations  and  developing  interbus  devices 
compatible  with  these  architectures.  To  enhance  the  flexibility  of  this 
program's  design  of  the  Advanced  Electrical  Power  System  (AEPS)  Simulator  and 
benefit  from  the  design  development  work  contemplated  in  the  PAVE  PILLAR'S 
Advanced  System  Integration  Development  (ASID)  Baseline  architecture 
development,  an  additional  task  was  defined.  In  this  task,  the  interbus 
processing  requirements  were  defined,  trades  were  conducted  to  select  an 
appropriate  unit  to  do  the  interbus  processor  function,  and  a  conceptual 
design  conducted  of  the  AEPS  and  its  support  hardware  and  software  for  the 
simulator. 

1.  SYSTEM  REQUIREMENTS  DEFINITION 

The  approach  was  to  examine  the  requirements  on  the  interbus  device  for  a 
generic  multibus  system,  then  narrow  the  scope  of  the  investigation  to  the 
specific  case  at  hand.  The  interbus  device  requirements  are  separated  into 
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generic  requirements,  specific  data  transfer  requirements,  and  specific 
processing  requirements  imposed  by  the  interbus  configuration.  The  system 
requirements  definition  with  observations  on  concepts  and  interrelations 
developed  during  the  course  of  the  requirements  definition  are  also  discussed. 

It  is  assumed  that  the  equipment  list  of  the  electrical  system  is  as  defined 
in  the  Phase  I  conclusion.  The  electrical  system  is  to  operate  as  closely  to 
the  Phase  I  definition  as  is  feasible  in  a  multibus  environment.  The  power 
handling  portion  of  the  system  will  not  be  affected.  The  avionic  system  will 
be  affected  only  by  the  removal  of  the  electrical  system  en  masse  from  the 
avionic  bus,  and  replacement  with  an  interbus  data  transfer  configuration.  No 
assumptions  will  be  made  in  the  system  requirements  definition  as  to  the 
identity  and  configuration  of  the  interbus  connection,  since  these  subjects 
are  investigated  by  the  trade  study.  It  is  assumed  that  the  PSPs  operate  as 
bus  controllers,  with  the  primary  PSP  as  primary  bus  controller,  and  backup 
bus  control  being  vested  in  the  backup  PSP. 

a.  Generic  Multibus  System  Configuration 

For  the  purposes  of  this  task,  a  generic  multibus  system  configuration  is 
developed.  Note  that  multibus  is  a  topological  label,  describing  the  way  in 
which  the  hardware  is  physically  interrelated.  The  buses  may  operate 
indeoendently,  or  they  may  operate  in  a  master/slave  relationship.  This  last 
organization  is  called  hierarchical.  The  difference  between  tne  two 
relationships  is  in  the  way  in  which  the  control  functions  interrelate. 
Generally  speakinq,  if  one  bus  modifies  its  operations  under  the  control  of 
another  bus,  then  the  architecture  is  termed  hierarchical. 

The  generic  multibus  configuration  used  in  this  task  is  shown  in  Figure  41. 

In  this  figure,  the  bus-to-bus  interconnection  is  visualized  as  a  logical 
function,  and  represents  a  device  or  devices,  possibly  in  parallel.  Figure  42 
illustrates  several  possible  interconnection  configurations.  These  are  not 
intended  to  fully  portray  all  possible  configurations,  merely  to  provide 
examples.  These  configurations,  and  others,  were  investigated  in  trade 
studies. 
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Regardless  of  configuration,  the  bus  interconnection  method  is  charged  with 
providing  a  data  path  for  timely  transfer  of  data  from  one  bus  to  another, 
potentially  in  both  directions.  Whether  the  respective  buses  are  controlled 
by  the  interbus  device,  only  one  bus  is  controlled,  or  neither,  is  of  little 
concern  except  to  possibly  simplify  the  actual  transfer  process.  Of  more 
critical  concern  is  whether  the  nature  of  the  function,  the  interbus  device, 
or  both,  requires  software  participation  in  the  transfer  process. 

Fortunately,  hardware  designs  are  currently  feasible  to  permit  transfer  of 
data  without  software  interaction.  This  is,  after  all,  essentially  the  action 
of  a  DAIS  remote  terminal  (RT),  except  that  one  side  of  the  DAIS  RT  is  not  a 
bus.  Connecting  two  of  these  devices  back-to-back  permits  the  transfer 
function. 

b.  Interbus  Data  Transfer  Requirements 

( 1 )  Type  of  Data 

Two  types  of  data  were  identified  for  communication  with  the  avionic  system. 
Discretes  which  would  be  received  from  the  avionic  system.  These  discretes 
are  translated  from  logical  signals  to  Boolean  data  by  the  avionic  system  and 
transmitted  as  Boolean  data  to  the  electrical  system. 

The  other  type  of  data  identified  for  communication  with  the  avionic  system  is 
controls  and  displays  ( C&O )  data.  This  data  is  transmitted  to  the  avionic 
sys^m.  This  data  is  anticipated  to  be  state  data  to  be  delivered  to  the  C4D 
system  by  the  avionic  system,  and  is  therefore  expected  to  also  be  Boolean 
data. 

(2)  Quantity  of  Data 

The  Phase  I  study  identified  83  discretes  from  each  of  the  three  electrical 
system  RTs  which  would  be  received  instead  from  the  avionic  system.  Therefore 
a  total  of  249  separate  Boolean  values  are  to  be  transferred  from  the  avionic 
bus,  through  the  interbus  configuration,  to  the  electrical  system. 


It  Is  estimated  that  a  similar  number  of  Boolean  values  are  to  be  transferred 
from  the  electrical  bus  to  the  avionics  bus  for  data  display.  The  exact 
number  is  based  on  the  formats,  quantities  and  depth  of  information 
displayed.  This  information  is  not  available  at  this  time.  The  conservative 
estimate  of  249  discretes  is  therefore  used  for  further  computations. 

(3)  Timing  Constraints 

The  Phase  I  report  specified  that  5%  of  the  data  must  be  collected,  reduced, 
and  distributed  in  50  msec,  and  that  the  remaining  95%  of  the  data  must  be 
handled  within  300  msec.  There  were  no  requirements  for  critically  timed 
data,  for  example  that  data  must  arrive  within  5  msec  of  a  qiven  time  or 
frequency. 

It  was  also  stated  that  the  50  msec  data  would  be  reduced  over  2  minor  cycles 
of  7.8125  msec  each.  Therefore,  four  minor  cycles  are  available  to  transmit 
data  to  and  from  the  PSP.  This  can  provide  a  fairly  strict  timing  constraint 
on  the  interbus  configuration. 

Assuming  that  the  controls  and  displays  are  not  integrated  directly  on  the 
avionic  bus,  but  instead  are  contained  on  another  bus  in  the  multibus 
topology,  similar  to  the  electrical  system  configuration,  then  one  minor  cycle 
will  be  consumed  in  making  the  data  available  to  the  avionic  bus.  Another 
minor  cycle  will  be  necessary  to  transmit  the  data  over  the  avionic  bus  to  the 
electrical  system  interbus  configuration.  One  additional  minor  cycle  will  be 
used  in  transmitting  the  data  to  the  ELMCs  or  RTs  following  data  reduction. 
Three  minor  cycles  have  therefore  been  consumed,  leaving  one  minor  cycle  to 
transfer  the  data  to  the  electrical  system  bus  and  to  transmit  the  data,  if 
necessary,  to  the  power  system  processor. 

Note  in  the  above  analysis  that  two  assumptions  were  made.  One  assumption  was 
that  the  C4D  system  would  be  on  another  bus  from  the  avionics  bus,  and 
directly  connected  to  the  avionic  bus.  The  other  assumption  was  that  the  data 
could  be  transferred  from  the  assumed  C&D  bus  to  the  avionic  bus  in  whatever 
time  remained  of  the  minor  cycle  in  which  the  data  was  made  available  to  the 
C&D/avionic  interbus  configuration.  If  this  assumption  can  be  made  for  the 
C&D/avionic  interface,  the  same  assumption  can  be  made  for  the  electrical 
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system/avionic  interface.  Thus,  the  additional  minor  cycle  available  can  be 
used  to  transmit  the  data  to  the  power  system  processor(s)  on  the  electrical 
bus.  A  timeline  diagram  of  this  situation  is  shown  in  Figure  43.  The 
implication  of  the  assumption  is  that  the  power  system  processor  is  not 
required  due  to  tine  constraints  to  being  in  the  interbus  configuration. 

As  can  be  seen  from  Figure  43,  the  situation  is  complicated  by  the  fact  that, 
generally  speakinq,  the  individual  buses  will  not  be  synchronized  in 
operation.  Observe  that  even  though  the  data  may  be  delivered  to  the  power 
system  processor  in  the  fourth  electrical  system  bus  minor  cycle  after  the 
data  was  available  to  the  C&D  system,  less  than  three  actual  minor  cycle 
periods  have  elapsed  before  the  data  was  delivered  to  the  power  system 
processors, .  If  the  avionic  bus  is  operating  at  a  higher  frequency  than  the 
assumed  128  minor  cycles  per  second,  this  performance  may  actually  improve. 

Another  concern  is  the  problem  of  encountering  a  race  condition  between 
deposit  of  data  in  one  side  of  the  interbus  configuration  and  extraction  of 
data  by  the  other  bus.  The  problem  is  generally  trivial  for  one-word 
transfers,  especially  if  a  parallel,  word-wide  data  path  is  used.  When  more 
than  one  word  is  to  be  transferred,  however,  the  words  are  transferred 
serially,  and  many  memory  controllers  permit  interleaving  of  memory  accesses 
to  improve  efficiency.  It  is  therefore  possible,  however  unlikely,  that  some 
data  from  an  incominq  message  is  transferred,  while  other  data  from  the  same 
incoming  message  is  not  seen  by  the  memory  until  after  the  memory  location  is 
accessed  by  the  retrieving  data  bus.  Two  solutions  to  this  problem  exist: 
first,  to  use  a  memory  with  a  lockout  feature,  permitting  one  bus  interface 
exclusive  access  to  memory  until  all  accesses  have  been  concluded  for  a  given 
message,  and  locking  out  the  other  bus  interface  in  the  meantime;  and  second, 
to  ">t  use  a  memory,  but  instead  provide  hardwired  interfaces  between  the  bus 
interfaces.  Two  common  techniques  are  available  in  this  latter  case, 
independent  of  the  interface-to-interface  technique.  The  first  is  to  disable 
communications  between  the  interfaces  while  either  interface  is  performing  bus 
operations,  which  essentially  causes  the  same  actions  as  the  dual -ported 
memory  with  the  lockout  feature,  and  the  second  technique  is  to  have  multiply 
buffered  communications  between  the  interfaces,  such  that  one  buffer  is  used 
while  the  other  is  being  accessed.  This  requires  multiples  of  two  buffers  in 
each  interface. 
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Figure  43.  Data  T ramfer  Timeline 


It  is  reasonably  clear  that  instantaneous  transfer  of  data  between  interfaces 
is  not  realistic.  The  points  where  this  timing  becomes  important  are  in  the 
transfer  from  the  C&D  bus  to  the  avionics  bus,  and  from  the  avionic  bus  to  the 
electrical  system  bus,  during  the  process  of  making  the  data  available  to  the 
power  system  processor.  No  transfer  time  is  required  to  be  allocated  during 
the  process  of  disbursing  the  resultant  data. 

Assuming  that  four  full  minor  cycles  are  used  in  bus  traffic,  and  two  full 
minor  cycles  are  used  in  processing,  then  the  50  msec  response  time 
requirement  dictates  that  the  two  transfer  processes  utilize  no  more  than  0.4 
minor  cycles,  or  3.125  msec.  Assuming  further  that  both  interfaces  operate 
equivalently,  then  each  interface  can  utilize  as  much  as  1.5  msec  to  transfer 
data. 

95%  of  the  data  is  operating  under  a  300  msec  turnaround  requirement,  with  16 
minor  cycles  allocated  to  processing  time.  This  permits  22.4  minor  cycles  for 
data  transfer  from  C&D  tc  the  ELMCs  via  the  PS?.  Obviously,  the  timing 
requirements  for  this  data  are  considerably  more  leniert  than  for  the 
remaining  5%  of  tne  data. 

(4)  Redundancy  Requirements 

The  interbus  interface  should  provide  at  least  one  redundant  data  path,  in  an 
effort  to  ensure  proper  control  of  the  electrical  system,  and  to  provide 
operational  information  to  the  PSPs  beyond  a  dual  PSP  failure.  The  redundant 
data  path  should  exist  in  a  physically  separate  location,  sufficient  to  negate 
the  possibility  of  ballistic  damage  occurring  to  all  data  paths  from  a  single 
strike.  An  individual  data  path  may  only  interface  with  one  side  of  each 
active/standby  1553B  data  bus,  in  such  a  way  that  one  data  path  is  accessed  by 
both  bus  controllers  for  normal  operations;  that  is,  if  the  avionic  processor 
normally  communicates  with  data  path  1,  then  the  electrical  bus  side  connected 
to  data  path  1  should  be  the  bus  side  normally  used  by  the  electrical  system. 
For  example,  if  both  buses  normally  operate  with  bus  side  A  as  the  active  bus, 
then  one  data  path  should  be  connected  to  bus  side  A  of  each  data  bus,  and  one 
data  path  should  be  connected  to  bus  side  B  of  each  data  path.  This 
configuration  is  shown  in  Figure  44. 
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Fault  tolerance  can  be  increased  by  providinq  another  set  of  data  paths  which 
are  cross-connected  as  illustrated  in  Fiqure  45,  such  that  one  side  of  the 
data  path  is  connected  to  the  active  bus,  and  the  other  side  is  connected  to 
the  standby  bus.  Thus,  changing  addresses  on  the  electrical  system  bus 
permits  selecting  a  different  bus  in  the  avionic  system,  and  vice  versa. 

If  each  interbus  device  contains  dual -redundant  bus  interfaces,  redundancy 
should  be  supplied  by  employing  dual -redundant  interbus  devices.  Each  bus 
interface  must  be  capable  of  accessing  one  bus  side  of  the  opposing  bus 
interface,  and  should  be  capable  of  accessing  both  bus  sides.  In  this  way, 
bus  side  A  of  the  electrical  system  can  access  either  bus  side  of  the  avionic 
system.  If  the  additional  capability  is  included,  the  interbus  configuration 
may  be  capable  of  automatically  acquiring  data  from  either  bus  side,  without 
outside  interference,  purely  on  the  basis  of  which  avionic  bus  side  last 
supplied  the  desired  information.  Equivalent  capability  should  exist  from  the 
point  of  view  of  the  avionic  system  bus.  Again,  the  LRUs  should  be  separated 
physically  to  minimize  the  possibility  of  a  single  strike  causing  all  data 
paths  to  fail. 

(5)  Reliability  Requirements 

Two  PSPs,  each  with  an  estimated  hardware  reliability  of  3000  hours  MTBF,  when 
operated  in  parallel,  provide  a  cumulative  MTBF  of  more  than  3.5  million 
hours.  To  permit  the  PSPs  to  operate  with  control  data  throughout  their 
operational  period,  the  interbus  configuration  should  also  have  more  than  3.5 
million  hours.  Past  the  point  at  which  both  PSPs  have  failed,  no  further  use 
can  be  made  for  the  data  supplied  by  the  avionic  bus,  and  no  traffic  can  move 
on  the  electrical  system  bus  from  lack  of  a  bus  controller.  Therefore,  upon 
failure  of  both  PSPs,  we  no  longer  have  a  requirement  for  interbus  data 
transfer.  The  reliability  of  the  interbus  configuration  in  this  instance  is 
required  to  be  in  excess  of  3.5  million  hours  MTBF. 

c.  Interbus  Processing  Requirements 

No  processing  of  interbus  data  is  required.  Some  processing  can  be  included, 
as  part  of  the  interbus  configuration,  to  compare  data  sent  to  the  redundant 
data  paths.  This  processing,  howevr-,  is  not  recommended,  due  to  the 
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impossibility  of  determining  which  data  path  is  faulty,  as  well  as  the 
observation  that  the  power  system  is  much  better  equipped  to  provide  the 
comparison  function  if  such  is  desired. 

d.  Requirements  Summary 

The  following  interbus  configuration  requirements  have  been  identified: 

o  All  data  will  be  Boolean; 
o  Data  will  be  transferred  in  both  directions; 

o  Each  direction  will  pass  249  unique  bits  (237  bits  8  times  per  second, 
and  12  bits  64  times  per  second); 
o  No  device  is  prohibited  from  use  due  to  timing  constraints; 
o  All  data  must  be  transferred  and  available  to  the  electrical  bus 
within  1.5  mseconds  after  receipt  on  the  avionic  bus.  No  time 
constraints  are  placed  on  transfer  from  the  electrical  bus  to  the 
avionic  bus  except  expediency; 

o  Redundant  paths  shculd  be  physically  separated  to  prevent  ballistic 
damage  from  one  strike  causing  all  interbus  connections  to  fail; 
o  A  specific  LRU  need  not  be  dually  redundant  within  the  LRU; 
o  Cumulative  MTBF  of  the  interbus  hardware  should  be  better  than  3.5 
mi  I  lion  hours  to  continue  supporting  PSP  operations  to  their  failure; 
and 

o  No  processing  capabilities  are  required  by  the  interbus  configuration. 
2.  INTERBUS  CONNECTION  DEVICE  EVALUATION 

a.  Identification  of  Interbus  Devices 

This  technical  investigation  will  examine  a  number  of  devices  to  determine 
whether  they  meet  the  system  requirements  definition  singly  or  in  combination 
with  other  devices,  and  the  restrictions  on  their  use  in  the  interbus 
configuration. 

The  device  candidates  are  a)  Generator  Control  Unit  (GCU);  b)  Electrical  Load 
Management  Center  (ELMO);  c)  DAIS  Remote  Terminal  (RT);  d)  Power  System 
Processor;  e)  Dedicated  RT;  and  f)  Special  Purpose  Interbus  Processor. 
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(1)  Generator  Control  Unit  (GCU) 


The  cost  of  hardware  development  in  a  technique  requiring  softw;rc  control 
would  probably  be  along  the  same  order  of  magnitude  as  the  cost  of  hardware 
development  for  a  device  designed  to  transfer  data  autonomously.  In  the  GCU, 
however,  the  hardware  development  cost  may  not  be  acceptable.  The  reason  is 
that  the  GCU's  internal  architecture  would  probably  be  streamlined  for 
communication  with,  and  control  by,  the  embedded  processing  element.  The 
second  1553B  dual -redundant  bus  interface  would  by  necessity  also  need  to  be 
under  control  of  the  processing  element,  thus  causing  a  need  for  software 
intervention.  The  design  of  modifications  to  the  software,  in  consideration 
of  the  functional  requirements  of  a  GCU,  would  probably  be  expensive,  and 
would  compromise  the  design  in  terms  of  being  able  to  react  to  generator 
faults  in  a  timely  manner,  especially  as  bus  loading  and  communications  with 
the  GCU  on  both  buses  increases.  Thus,  the  busier  the  system,  the  poorer  the 
performance  of  the  generator  control  function  of  the  GCU  becomes. 

The  hardware  reliablity  of  the  device  would  also  decrease,  perhaps 
drastically,  due  to  the  additional  hardware  necessary  to  implement  the 
functional  capability.  The  fault  tolerance  of  the  device  could  be  increased 
in  a  number  of  ways,  increasing  cost.  However,  as  noted  in  the  discussion, 
the  GCU,  in  company  with  two  other  devices,  could  be  acceptable  in  reliability 
terms  with  a  fairly  low  MTBi  for  the  data  transfer  function. 

The  original  function  of  the  GCU  could  therefore  be  adversely  affected  in  two 
ways.  First,  the  processing  time  necessary  to  handle  an  additional  interface 
will  likely  more  than  double,  and  the  reliability  of  the  device  to  handle  the 
control  of  the  generator  would  decrease. 

(2)  Electrical  Load  Management  Center  (ELMC) 

An  ELMC  represents  a  slightly  different  situation  than  a  GCU.  Considerably 
less  Interface  with  the  bus  may  be  expected,  so  that  the  bus  Interface 
operates  more  autonomously  than  in  a  GCU.  Therefore,  the  additional  software 
modifications,  for  the  most  part,  do  not  exist,  but  are  limited  to 
initialization  of  the  bus  interfaces  on  startup  and  handling  of  bus  errors 
observed  by  the  bus  Interfaces. 
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The  hardware  reliability  and  fault  tolerance  issues  remain,  howeve. ,  for  the 
hardware  modification.  In  the  case  of  an  ELMC,  it  is  equally  critical  to 
minimize  the  decrease  in  reliability  represented  by  additional  hardware,  in 
view  of  the  original  function  performed  by  the  ELMC.  While  the  probability  of 
an  ELMC  failing  during  the  mission  is  only  .2%,  this  figure  is  still  five 
orders  of  magnitude  higher  chance  of  failure  than  the  parallel  PSP 
reliability.  Thus,  it  would  not  be  reasonable  to  decrease  reliability  any 
further. 

(3)  DAIS  Remote  Terminal  (RT) 

The  addition  of  a  second  1553B  dual -redundant  bus  interface  increases  cost  and 
complexity,  thereby  decreasing  reliability.  These  RTs  stand  a  .1%  chance  of 
failure  *n  flight.  Again,  the  hardware  reliability  of  this  device  cannot 
stand  much  decrease.  In  this  case,  the  original  function  of  the  devices  is 
not  affected,  since  the  device  is  essentially  performing  the  same  function  as 
before. 

The  development  cost  of  such  a  device  essentially  consists  only  of  packaging 
the  additional  elements  and  inserting  them  into  the  LRU,  with  some  minor 
rewirinq  of  the  backplane  possible.  No  software  is  affected,  since  none  is 
resident  in  the  device. 

The  simplest  development  technique  would  be  to  build  a  separate  RT,  identical 
to  the  first,  except  with  different  backplane  connections,  and  attached  to  a 
different  data  bus.  The  backplanes  would  then  require  an  interfacing  element, 
such  as  a  dual -ported  memory.  Alternately,  the  second  RT  module  could  be 
built  using  the  same  backplane,  constituting  a  modification  to  the 
archi tecture . 

This  device  could  easily  be  expanded  to  include  additional  or  different  data 
being  transferred,  within  the  limits  of  the  1553B  subaddresses  and  word  counts 
per  subaddress  as  specified  in  MIL-STD-1553B.  Some  degradation  in  performance 
would  probably  occur  as  the  device  became  more  fully  loaded,  but  as  long  as 
the  l.b  msec  data  transfer  criterion  was  met,  the  resulting  effects  elsewhere 
in  the  architecture  should  be  negligible. 
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(4)  Power  System  Processor  (PSP) 


Two  options  exist  for  using  a  PSP  as  an  interbus  device:  add  a  second  bus 
Interface  to  an  AN/AYK-15A  processor,  or  change  to  a  MIL-STD-1750A  Instruction 
Set  Architecture  (ISA)  processor.  The  addition  of  a  second  bus  interface  to  a 
1750  processor  does  not  constitute  the  better  solution,  for  two  reasons . 

First,  the  instruction  set  is  not  optimized  for  more  than  one  bus  interface. 

In  fact,  at  least  two  such  machines  now  exist.  These  machines  permit  access 
to  the  second  bus  interface  by  expanding  the  instruction  set,  such  that  two 
separate  mnemonics  were  provided  for  the  separate  bus  interfaces.  This 
requires  wasteful  code  generation  due  to  a  requirement  to  either  branch  any 
time  a  parameterized  bus  interface  access  was  to  occur,  or  to  actually 
implement  identical  code  except  for  the  instances  when  the  different  bus 
interface  is  addressed.  The  second  drawback  with  the  stop-gap  multibus 
processor  is  that  they  are  relatively  quickly  designed,  and  therefore  will 
probably  suffer  drastically  in  terms  of  hardware  reliability. 

The  alternative  it  the  MIL-STD-1750A  ISA  processor.  This  macnine  also 
currently  exists.  Its  instruction  set  is  optimized  for  multiple  bus 
interfaces.  The  reliability  of  these  devices  is,  like  the  AN/AYK-15A,  roughly 
3000  hrs  MTBF. 

The  cost  of  hardware  modification  is  therefore  minimal.  The  software  in 
either  machine  must  be  modified  from  the  DAIS  type  of  existing  executives  to 
permit  control  of  more  than  one  bus  interface.  This  software  development  cost 
is  less  for  the  I750A  machine,  due  to  the  optimized  instruction  set,  but  will 
still  be  considerable.  The  biggest  effort  would  be  to  modify  the  data  base, 
and  the  software  to  accommodate,  and  ..o  modify  the  interrupt  structure  to 
handle  multiple-sourced  interrupts  and  to  streamline  interrupt  operations. 

A  Type  B5  (Part  I)  specification  per  MIL-STD-490  has  been  released  within  the 
Boeing  Company  which  describes  the  functional  requirements  of  a  DAIS  type  of 
executive  to  execute  in  a  multibus  atmosphere.  Other  than  the  data  transfer 
function,  which  was  designed  with  a  different  functional  environment  in  mind, 
the  Part  I  functional  requirements  for  the  Multibus  Synchronous  Executive 
(MBSE)  includes  the  functional  requirements  of  the  executive  required  for  this 
application.  The  MBSE  functional  requirements  are  sufficient  and  necessary 


for  this  application.  Note  that  the  executive  is  hardware-dependent,  and  will 
therefore  require  modification  for  a  machine  with  a  bus  interface  not 
patterned  after  the  AN/AYK-15A. 

The  cost  of  the  applications  software  is  not  affected  by  the  use  of  a 
MIL-STD-1750A  ISA,  by  the  modifications  to  the  executive,  or  by  the  use  of  the 
device  in  the  interbus  configuration. 

(5)  Dedicated  Remote  Terminal  (RT) 

This  concept  permits  the  designer  the  flexibility  of  designing  with  the 
application  driving  the  functional  requirements,  rather  than  trying  to  build 
around  or  through  an  existing  architecture.  The  device  is  freed  from  the 
constraints  of  not  affecting  the  original  functional  requirements  of  the  RT, 
since  of  course  there  were  none.  A  new  design  is  not  necessary  for  the  bulk 
of  the  device,  since  existing  RT  designs  can  be  used.  The  development  cost  in 
this  case  comes  from  the  design  of  the  common  backplane  on  which  the 
individual  RTs  will  operate. 

The  reliability  of  this  device  should  be  better  than  the  DAIS  RTs  due  to  the 
deletion  of  the  signal  conversion  hardware  which  accounts  for  the  greatest 
part  of  the  relatively  low  reliability.  It  is  f  pected  that  the  reliability 
of  this  device,  in  terms  of  MT3F,  could  perhaps  exceed  that  of  a  1750/1750A 
processor.  No  software  development  is  necessary,  only  a  minimal  amount  of 
hardware  design  is  required,  and  existing  RT  hardware  can  be  utilized, 
proviaing  a  cheap,  reliable,  and  efficient  design. 

Fault  tolerance  in  this  case  is  limited  by  the  RT-to-RT  interface  circuitry. 
Little  can  be  done  to  increase  fault  tolerance  in  this  area  due  to  the 
requirement  for  single-point  interface  with  each  RT.  Any  fault  tolerance 
increases  therefore  require  hardware  modifications  to  the  RTs  themselves.  The 
interbus  configuration  will  probably  require  dual -redundancy  for  reliability 
reasons,  thus  satisfying  the  interbus  configuration  fault  tolerance  problem, 
so  that  additional  fault-tolerance  in  each  device  of  the  configuration  will 
not  be  necessary.  The  device  should  easily  be  capable  of  accepting  any  future 
traffic  demands,  up  to  the  limitations  placed  on  one  device  by  MIL-STD-1553B. 
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(6)  Special  Purpose  lnterbus  Processor 


The  use  of  a  1750A  processor  has  already  been  described  in  paragraph  (4) 
above.  The  difference  in  this  instance  is  that  no  applications  software  is 
required.  The  local  executive  is  therefore  unnecessary.  This  can  increase 
software  modification  costs,  because  the  '  )cal  executive  can  be  stubbed  to 
increase  the  time  available  for  master  executive  operations,  while  all  the 
software  modifications  still  need  to  be  made  to  the  master  oxecut’\j. 

An  additional  cost  exists  for  this  option  also,  in  that  the  total  cost  of  the 
processor  is  allocated  solely  to  the  interbus  transfer  function,  rather  than 
having  other  functions  sharing  in  the  cost.  Also,  the  processing  capability 
and  memory  purchased  are  much  more  than  required,  so  that  the  greatest 
majority  of  the  processing  capability  will  be  left  idle  and  unneeded. 

The  reliability  of  this  device,  as  has  been  previously  stated,  is  on  the  order 
of  3000  hours  MTBF .  No  outstanding  fault  tolerance  features  of  this  typ  of 
processors  was  noted,  although  isolated  instances  may  exhibit  some  higher 
degree  of  fault  tolerance.  Thus,  for  fault  tolerance  to  be  present  in  the 
interbus  configuration  with  this  device  present,  the  fault  tolerance  must  be 
through  topological  arrangement  of  the  devices. 

b.  Selection  of  the  lnterbus  Devices 

The  use  of  a  GCU  or  an  ELMC  is  not  considered  viable  in  light  of  the  desire  to 
minimize  the  effect  on  existing  functional  requirements,  development  cost,  and 
reliability  when  other  devices  are  available.  The  use  of  a  special  purpose 
interbus  processor  is  not  considered  a  cost-effective  solution,  althouqh  it 
does  present  opportunities  for  pre-processing  and  bus  monitoring  which  may,  at 
a  later  time,  be  appropriate  to  investigate. 

The  remaining  options  are  therefore  the  use  of  a  DAIS  RT,  a  dedicated  RT,  or  a 
PSP.  Table  6  shows  relative  merits  of  these  three  devices.  It  must  be  kept 
in  mind  that  these  three  device  candidates,  as  indicated  by  the  table,  must  be 
used  in  a  multiple-  redundancy  configuration  to  meet  reliability  requirements, 
and  may  be  used  in  some  combination.  If  a  uAIS  RT  is  used  in  the 
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TABLE  6  RELATIVE  MERITS  OF  INTERBUS  DEVICE  CANDIDATES 


AREA  OF  CONCERN 

- — i 

DAIS  RT 

DEDICATED  RT 

PSP 

COST: 

ACQUISITION 

VERY  LOW 

LOW 

MEDIUM 

HARDWARE 

DEVELOPMENT 

MEDIUM 

LOW 

NONE 

SOFTWARE 

DEVELOPMENT 

NONE 

NONE 

MEDIUM 

OPERATING 

LOW 

LOW 

LOW 

RELIABILITY: 

HOURS  MTBF 

2000  (EST) 

3500  (EST) 

3000 

NUMBER  OF 

DEVICES  REQUIRED 

3 

2 

2 

EFFECT  ON  SYSTEM 

H/W  RELIABILITY 

.0005  DEC. 

NEGLIGIBLE 

NO  EFFECT 

RESULTING  SYSTEM 

H/W  RELIABILITY 

.9720 

.9726 

.9726 

FAULT  TOLERANCE: 

CURRENT 

MEDIUM 

MED*'IM 

POTENTIAL 

MEDIUM-HIGH 

HIGH 

MEDtuM-HlGH 

COST  OF  ACHIEVING 

POTENTIAL 

MEDIUM-HIGH 

MEDIUM 

HIGH 

EFFECT  OF  FAILURE 

ON  PSP  OPERATION 

DEGRADED 

DEGRADED 

NONE 

INTERBUS  TRANSFER: 

REQUIRED 

YES 

YES 

NO 

BUS  LOADING 

HIGHER 

HIGHER 

LOWER 

GROWTH  POTENTIAL: 

MORE  DATA 

GOOD 

BEST 

GOOD 

DIFFERENT  TYPES 

OF  DATA 

GOOD 

GOOD 

GOOD 

PREPROCESSING 

NONE 

NONE 

GOOD 

BUS  ADDRESSES: 

AVIONIC  BUS 

3 

2 

2 

ELECTRICAL  BUS  (ADDITIONAL) 

3 

—  . . -  .  -  j 

2 

0 
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configuration,  then  at  least  three  devices  must  be  used  to  provide  data 
transfer  through  failure  of  both  PSPs,  since  a  parallel  combination  of  the 
DAIS  RT  and  another  device  does  not  provide  sufficient  reliability. 

A  few  comments  on  some  of  the  areas  of  concern  listed  in  Table  6  are  in 
order.  In  the  area  of  cost,  the  acquisition  cost  includes  only  the  cost  of 
building  the  machine  and  the  cost  of  hardware  associated  with  installation  and 
checkout  of  the  device.  The  hardware  development  cost  includes  engineering 
and  shop  manhours  and  utilization  of  design  tools  necessary  to  design  and  t^st 
the  modifications  to  the  existing  hardware.  Operating  costs  consist  of  all 
costs,  including  repair,  facilities,  and  utilities  necessary  to  operate  and 
maintain  the  hardware  during  software  development  and  normal  laboratory 
operations,  and  does  not  include  those  costs  incurred  during  development. 
Operating  costs  are  recurring.  Acquisition,  hardware  development,  and 
software  development  costs  are  non-recurring. 


The  number  of  devices  required  for  reliability  represents  the  number  of 
identical  devices  in  parallel  which  are  necessary  to  provide  3.5  million  hours 
MTBF.  The  required  reliablity  is  the  reliability  of  the  two  electrical  system 
PSPs  in  dual -redundant,  active/standby  operating  mode.  The  system  hardware 
reliability  values  and  perturbations  are  based  on  a  reliability  value  of 
.9726,  achieved  using  the  following  equation: 

k  =  rap  relmc  rrt  rgcu  <1-<1-rpp)  *  ^ 


Note  that  this  is  the  equation  used  when  the  PSPs  are  used  in  parallel  as  the 
interbus  configuration.  The  equation  used  when  two  interbus  devices  are  used 
is  identical  to  the  above  equation,  with  the  addition  of  a  term  for  the 
interbus  devices: 

R  =  RAP  relmc  rrt  rgcu  (1-(1-Rpp*  )  (1-(--RDrt>  )  (2) 


The  use  of  the  three  OAI^  RTs  requires  a  reduced  reliability  value  for  three 
of  the  RTs,  resulting  in  the  following  equation: 


R  "  RAP  RELMC  RRT  RERT  RGCU  d-d-Rpp*  ) 


(3) 
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In  all  three  equations  above,  the  reliability  terms  are  computed  by 

R  =  e-T'HTBF 

where  T  Is  2.5  hours,  representing  the  required  mission  time.  Table  7  shows 
the  subscripts.  Identifies  the  device  Indicated  by  the  subscript,  and  gives 
the  MT8F,  In  hours,  of  the  Indicated  device.  Equation  1  also  represents  the 
equation  describing  the  hierarchical  architecture  of  Phase  I,  when  modified  to 
use  seven  ELMCs  and  two  PSPs  In  active/standby  configuration. 


TABLE  7  IDENTIFICATION  OF  SUBSCRIPTS  IN  RELIABILITY  EQUATIONS 


JBSCRIPT 

DEVICE  IDENTIFICATION 

MTBF  (HRS) 

AP 

AVIONICS  PROCESSOR 

3000 

PP 

POWER  SYSTEM  PROCESSOR 

3000 

ELMC 

ELMC 

1159 

RT 

UNMODIFIED  RT 

2354 

GCU 

GENERATOR  CONTROL  UNIT 

4000 

DRT 

INTERBUS  DEVICE 

3500 

ERT 

DAIS  RT 

2000 

The  gro /th  potential  area  of  concern  applies  to  the  capability  of  the  selected 
Interbus  configuration  to  expand  operationally  by  Increasing  data  throughput, 
by  handling  different  types  of  data  than  Boolean,  and  by  providing  pre-  or 
post-processing  capability  at  a  later  date  as  the  system  expands,  and  also 
provides  a  measure  of  flexibility  in  the  application  of  these  devices  in  other 
point  designs.  These  potentials  are  given  assuming  that  the  minimum  number  of 
like  devices  is  present,  such  that  no  one  configuration  is  near  saturation 
with  the  same  throughput. 

The  fault  tolerance  area  of  concern  is  for  each  line  replaceable  unit  (LRU)  in 
the  interbus  configuration.  The  fault  tolerance  of  the  interbus  configuration 
as  a  whole  is  primarily  determined  by  the  topological  arrangement  of  the 
devices,  with  the  fault  tolerance  of  the  individual  devices  In  the 
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configuration  being  of  secondary  importance.  The  conclusion  that  no  effect  is 
felt  on  PSP  operations  as  a  result  of  failure  of  the  PSP  while  in  the  interbus 
configuration  is  supported  by  the  observation  that  if  the  PSP  has  failed  as  an 
interbus  device,  then  PSP  operations  have  been  isolated  from  one  data  bus  or 
the  other,  so  that  no  effect  can  be  felt  by  a  functionally  "dead"  processor. 

An  analysis  of  Table  6  shows  that  the  use  of  a  DAIS  RT  as  an  interbus  device 
has  advantage  in  only  two  areas  of  concern:  acquisition  cost,  assuming  the 
original  DAIS  type  of  RT  is  already  available,  along  with  the  associated 
software  development.  Compared  to  this,  the  dedicated  RT  and  the  PSP  are 
about  equally  split  for  the  remaining  areas  of  concern,  with  a  slight 
advantage  being  enjoyed  by  the  use  of  a  PSP.  It  is  therefore  recommended  that 
the  interbus  configuration  consist  of  some  combination  of  PSP  and/or  a 
dedicated  RT. 

c.  Identification  of  Redundancy  Mode 

This  trade  study  will  investigate  the  attributes  of  various  candidate 
redundancy  schemes,  and  recommend  one  scheme  for  implementation.  The 
candidate  redundancy  mode  schemes  to  be  considered  are: 

o  Active/standby  mode  with  a  "cold"  standby;  that  is,  some  time  is 
generally  required  after  recognition  of  failure  of  the  active  device 
before  the  standby  device  is  capable  of  transferring  valid  data; 

o  Active/standby  mode  with  a  “hot"  standby;  that  is,  the  standby  device 
is  immediately  capable  of  supplying  valid  data  on  failure  of  the 
active  device;  and 

o  Active/active  mode;  that  is,  both  devices  are  constantly  being 
accessed  for  data. 

The  standby/standby,  or  "on  request"  scheme  is  not  considered  since  this 
scheme  is  inherently  incompatible  with  a  synchronous  data  bus  information 
transfer  system  (ITS)  of  the  type  supported  by  the  DAIS  family  of  executives. 
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It  is  assumed  that  two  data  paths  of  one  recommended  interbus  device  each 
constitutes  the  interbus  configuration.  This  is  the  most  cost  effective 
configuration  necessary  to  meet  the  required  reliability  and  redundancy.  The 
fault  tolerance  aspect  of  the  configuration  is  directly  associated  with  the 
way  in  which  redundancy  is  implemented.  The  three  candidate  redundancy 
schemes  are  illustrated  in  Figure  46. 

Option  1  represents  an  active/standby  configuration.  One  device  is  designated 
the  primary  interbus  device,  and  the  other  is  backup.  The  primary  device  is 
actively  accessed  for  data  and  with  data,  while  the  backup  is  available  for 
use  on  failure  of  the  active,  primary  device.  In  this  option,  the  standby 
device  is  referred  to  as  a  "cold"  standby,  since  the  data  is  supplied  to  the 
backup  for  transfer  only  on  failure  of  the  primary  device.  The  disadvantage 
is  that  by  this  arrangement,  all  accesses  of  the  backup  device  between  the 
time  the  primary  fai^s  and  the  time  data  is  made  available  from  the  other  bus 
will  yield  essentially  indeterminate  data. 

This  drawback  leads  directly  to  Option  2,  in  which  the  problem  is  resolved  by 
providing  the  data  to  both  interbus  devices  as  a  normal  operation.  In  this 
way,  upon  failure  of  the  primary  device,  the  "hot"  standby  already  has  valid 
data  available  on  the  requesting  bus.  The  drawback  of  this  option  is  that  bus 
loading  is  increased  by  the  need  to  supply  data  to  two  addresses  instead  of 
just  one. 

Option  3  is  a  variation  of  Option  2  in  which  the  redundant  data  available  to 
the  second  device  is  acquired  and  used  to  validate  the  data  retrieved  from  the 
first  device.  In  this  option,  of  course,  the  designations  "primary"  and 
"backup"  are  meaningless,  but  these  labels  will  be  retained  for  identification 
purposes.  Two  drawbacks  are  found  in  this  option.  The  first  drawback  is  that 
even  more  bus  loading  is  required  than  in  Option  2,  due  to  the  need  to  acquire 
data  from  two  sources  instead  of  one.  The  second  drawback  is  the  logical 
problem  of  determining  a  course  of  action  should  the  two  data  disagree. 

It  is  not  reasonable  to  expect  that  a  technique  for  identifying,  reporting, 
and  locating  the  source  of  errors  over  this  type  of  interface  will  be  anytning 
less  than  large  and  clumsy.  Handling  the  error  would,  of  course,  be  simple: 
command  the  electrical  system  to  remove  power  to  the  offending  device. 
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However,  the  isolation  problem  alone  prevents  consideration  of  these 
techniques  within  the  scope  of  this  report.  Therefore,  the  only  available 
action  is  to  make  assumptions  regarding  the  true  value  of  the  discrepant  bit. 

The  assumption  can  be  made  that  the  bit  calling  for  a  reversal  in  value  is 
incorrect,  essentially  requiring  agreement  in  the  two  data  for  a  change  to  be 
made  effective.  Alternately,  the  assumption  can  be  made  that  the  bit 
indicating  that  the  value  did  not  change  is  incorrect,  which  permits  cycling 
of  bit  values  in  the  event  that  the  discrepancy  persists.  If  the  validity 
option  is  selected,  i '  is  recommended  that  the  policy  of  rule  by  agreement  be 
adopted. 

An  additional  drawback  to  Option  3  revealed  above  is  that  software  is  required 
to  perform  this  comparison.  The  software  may  be  located  in  an  interbus 
device,  therefore  requiring  the  presence  of  at  least  one  PSP,  or  the  software 
may  be  located  in  a  PSP  which  is  not  the  interbus  device.  This  last  option  is 
recommended,  since  in  the  first,  one  additional  data  transmission  may  occur 
following  verification,  thereby  decreasing  to  some  minor  degree  validity  of 
the  transferred  data. 

The  major,  and  potentially  system-crippling,  drawback  of  Option  1  should 
effectively  remove  that  option  from  consideration.  The  additional  bus 
loading,  and  the  requirement  for  software  intervention,  should  cause  Option  3 
to  be  much  less  highly  regarded  than  Option  2,  with  no  offsetting  drawbacks  in 
Option  2.  Therefore,  the  recommended  redundancy  mode  is  active/standby,  with 
a  "hot"  standby.  This  selection  places  no  restriction  on  the  interbus 
configuration. 

d.  Identification  of  Interbus  Configuration 

This  section  will  investigate  the  attributes  of  a  number  of  different 
topological  arrangements  of  interbus  devices.  Following  the  investigation, 
the  device  configurations  will  be  compared  and  a  single  recommended  candidate 
configuration  presented. 

The  architectural  candidates  which  will  be  investigated  in  this  trade  study 
are: 
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o  Two  dedicated  RTs; 

o  Two  PSPs; 

o  One  dedicated  RT  and  the  primary  PSP; 

o  One  dedicated  RT  and  the  backup  PSP. 

The  alternative  of  using  only  one  dedicated  RT  to  constitute  the  interbus 
configuration  was  rejected  due  to  the  need  to  provide  3.5  million  hours  of 
combined  MTBF.  Two  parallel  data  paths  were  considered  the  cheapest  solution 
permitting  the  required  redundancy  and  reliability.  One  device  in  each  data 
path  was  considered  cheapest,  simplest,  and  most  reliable.  Earlier  assessment 
identified  the  use  of  the  dedicated  RT  and/or  PSPs  as  the  most  suitable 
interbus  devices.  The  resulting  list  of  possible  combinations  of  devices, 
given  the  topological  restraints,  is  as  given  above.  The  topological 
configurations  are  illustrated  in  Figure  47. 

From  paragraph  c  it  was  concluded  that  the  use  of  the  active/,,hotu  standby 
redundancy  mode  was  most  suitable.  This  mode  was  stated  as  not  affecting 
device  combination,  and  will  therefore  be  assumed  as  the  redundancy  mode  for 
all  options. 

The  primary  evaluation  criteria  will  be  performance.  The  ease  with  which 
fault  tolerance  and  redundancy  are  implemented  is  one  aspect  of  performance. 
Other  aspects  include  effects  on  bus  loading  of  each  bus;  simplicity  of  normal 
operations,  backup  operations,  and  the  transition  from  normal  to  backup 
operations;  arid  the  degree  of  degradation  in  reliability  and  operating 
validation  during  backup  operations. 

The  effect  on  the  total  system  operation  in  the  event  of  failure  of  the 
interbus  configuration  is  the  same,  regardless  of  which  devices  constitute  the 
configuration,  or  their  topological  arrangement:  communication  between  the 
avionic  bus  and  the  electrical  bus  is  terminated.  If  the  two  electrical 
system  PSPs  constitute  the  interbus  configuration,  then  the  control  of  the 
interbus  system  is  lost,  as  well  as  the  interbus  communication  facility.  In 
this  case,  however,  since  the  PSPs  failed,  it  makes  no  difference  whether  they 
were  communicating  with  the  avionic  bus  or  not.  Thus,  this  situation  is  no 
worse  than  any  other.  The  only  concern  is  whether  any  additional  work  is 
associated  with  the  communication  function,  and  whether  this  additional  work, 
if  any,  could  result  in  the  premature  failure  of  the  PSPs. 
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The  1750A  processor  operates  under  approximately  the  same  reliability  as  the 
1750  device  currently  planned  for  implementation  as  PSP  in  the  Phase  I 
integrated  system.  These  processors,  in  use  in  the  interbus  configuration, 
are  not  being  required  to  perform  any  unusual  processing  or  an  unusual  amount 
of  processing.  Thus,  it  does  not  appear  that  any  factor  would  contribute  to 
the  premature  failure  of  the  PSP  if  it  were  to  operate  in  the  interbus 
configuration.  Hence  the  initial  impression  that  the  PSP  is  at  a  disadvantage 
in  the  interbus  configuration  is  seen  to  not  be  true.  The  conclusion, 
therefore,  is  that  no  advantage  or  disadvantage  is  associated  with  using  any 
particular  device  in  the  interbus  configuration  from  the  point  of  view  of 
affecting  total  system  operation  significantly. 

Following  failure  of  the  interbus  configuration,  any  PSPs  not  in  the  interbus 
configuration  would  be  capable  of  operating  in  a  degraded  mode,  controlling 
the  electrical  system  without  benefit  of  the  data  provided  by  the  avionic 
system.  The  situation  is  actually  slightly  better  in  the  integrated 
configuration  in  that  the  source  of  the  avionic  data  received  by  the  PSP  may 
have  been  a  device  other  than  the  avionic  processor,  in  which  case  the  data 
would  still  have  been  available  to  the  PSP.  In  the  multibus  configuration,  we 
must  have  a  PSP  as  a  member  of  the  interbus  configuration  to  permit  the  same 
capability.  This  is  perhaps  the  only  system-wide  consideration  which  favors 
one  interbus  configuration  over  another. 

Four  candidate  interbus  configurations  will  be  investigated  below.  The  four 
candidates  are  shown  in  Figure  47.  In  all  candidate  investigations,  the  "hot" 
standby  redundancy  mode  will  be  used. 

The  use  of  two  dedicated  RTs  as  the  interbus  devices  leads  to  a  decrease  in 
electrical  system  architectural  reliablity  due  to  the  inclusion  of  two 
additional  devices,  albeit,  in  parallel,  in  the  system  equipment  complement. 
The  reliability  equation  for  this  interbus  configuration  is: 

R  =  RELMC  RRT  RAP  {l-(1'Rpp)  )  (1'(1"rdrt*2*2  RGCU  =  ,9726 

This  is  in  comparison  with  the  reliablity  value  of  .9726  for  the  case  of  two 
PSPs  in  parallel  as  the  interbus  configuation.  The  first  significant  digit  of 
change  is  in  the  seventh  decimal  place. 
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This  system  also  leads  to  isolation  of  the  PSPs  from  the  source  of  the  avionic 
data.  That  is,  in  the  event  of  failure  of  the  avionic  bus  controlled s),  the 
PSPs  will  have  no  access  whatsoever  to  the  avionic  bus  to  retrieve  the  data 
normally  supplied  by  the  avionic  bus.  Two  options  are  available  in  this 
case.  The  avionic  data  can  be  brought  in  redundantly  to  the  three  RTs  in  the 
electrical  system,  effectively  implementing  the  non-integrated  configuration 
of  Phase  I.  This  option  is  probably  not  feasible  for  the  general  case,  since 
some  data  may  have  been  supplied  by  the  avionic  processor.  Insufficient 
definition  of  the  avionic  data  is  available  to  support  or  to  oppose  this 
position.  Worst  case  indicates  that  the  avionic  processor  would  supply  the 
data,  so  that  it  cannot  be  redundantly  supplied.  The  alternate  option  is 
therefore  the  only  feasible  alternative,  which  is  to  continue  operation  in  a 
degraded  mode.  The  degraded  mode  can  either  be  using  the  last  data  received 
from  the  avionic  system  or  a  predefined  set  of  data.  With  two  special  purpose 
interbus  processors  as  the  interbus  configuration,  we  cannot  determine  that 
the  avionic  processor  has  failed,  so  we  must  use  the  data  available,  which 
will  be  the  last  data  sent  by  the  avionic  processor. 

The  use  of  the  PSPs  in  the  interbus  configuration  provides  the  baseline 
reliablity  value  of  .9726  used  above.  The  isolation  of  the  PSPs  is  solved  in 
this  configuration,  since  the  PSPs  are  capable  of  directly  communicating  with 
the  avionic  bus.  Note  that  the  problem  of  retrieving  data  from  the  avionic 
bus  if  the  data  was  supplied  by  a  failed  avionic  processor  is  still  not 
solved,  so  that  in  this  case  as  well,  the  last  data  available  should  be  used. 
The  PSPs  would  have  the  capability  of  controlling  the  avionic  bus,  providing 
some  additional  backup  for  the  avionic  bus,  although  the  computations  of  the 
avionic  processor  would  still  be  lacking. 

A  consideration  in  this  case  is  whether  the  primary  PSP  will  continue  to 
include  a  synopsis  of  the  avionic  data  to  the  backup  PSP  as  a  part  of  the 
regularly  transmitted  backup  data.  The  disadvantage  is  a  .4%  increase  in  bus 
loading  on  the  electrical  bus,  and  the  advantage  is  the  fact  that  the  two  PSPs 
are  known  to  be  in  agreement  as  to  the  data  being  used.  It  is  recommended 
that  this  practice  be  followed. 

It  is  recommended  also  that  the  primary  PSP  be  considered  the  primary  device 
in  the  interbu?  configuration,  thus  not  requiring  the  additional  electrical 
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bus  loading  necessary  to  transmit  the  avionic  data  from  the  backup  PSP  to  the 
primary  PSP  on  a  regular  basis. 

This  configuration  has  the  advantage  of  having  the  lowest  bus  loading  figure 
of  all  the  configurations,  requiring  only  regular  backup  data  to  the  backup 
PSP  in  addition  to  normal  data  bus  loading.  This  configuration  also  has  the 
advantage  of  requiring  that  only  one  bus  address  have  C&D  data  sent  to  it  to 
support  the  "hot"  standby  redundancy  mode,  since  one  of  the  devices,  the 
primary  PSP,  already  has  the  data  available.  Bus  loading  also  decreases  on 
failure  of  the  primary  PSP,  since  the  backup  PSP  need  only  carry  on  normal 
electrical  system  bus  operations,  with  no  backup  data  transmissions  and  no 
transmissions  to  support  "hot"  standby  redundancy  required. 

The  third  configuration  of  devices  for  interbus  communication  is  the  use  of 
one  dedicated  RT  and  the  primary  PSP.  In  this  situation,  the  use  of  the 
primary  PSP  as  the  primary  interbus  device  is  the  recommended  configuration. 
During  normal  operations,  only  data  backup  transmissions  to  the  backup  PSP  and 
redundancy  communications  to  the  dedicated  RT  are  necessary,  since  the  primary 
PSP  already  has  the  avionic  data  available.  Failure  of  the  primary  PSP  forces 
the  backup  ^SP  to  acquire  the  avionic  data  from  the  dedicated  RT  interbus 
device.  Thus,  bus  loading  decreases  from  not  requiring  backup  and  redundancy 
transmissions,  but  also  increases  due  to  acquisition  of  the  avionic  data  from 
the  interbus  device.  This  configuration  is  therefore  as  good  as  the  dual -PSP 
configuration  during  normal  operations  and  as  bad  as  the  dual  dedicated  RT 
configuration  during  backup  operations. 

The  reliability  of  this  configuration  is  given  by  the  equation 

R  =  RELMC  rrt  RAP  ll~(1'Rpp)2  (1‘RDRT^  RGCU  =  *9726 

Again,  this  is  compared  to  the  reliability  of  .9726  with  the  parallel  PSP 
configuration.  The  first  unreliable  digit  is  in  the  sixth  decimal  place. 

The  fourth  configuration  utilizes  an  dedicated  RT  interbus  device  in 
conjunction  with  the  electrical  system's  backup  PSP.  The  hardware  reliablity 
equation  for  this  configuration  is  identical  to  that  shown  for  the  third 
configuration  above,  so  that  the  results  are  identical.  In  this 
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configuration,  the  primary  PSP  must  acquire  the  avionic  data  from  one  interbus 
device  or  the  other.  The  choice  is  essentially  arbitrary.  On  failure  of  one 
interbus  device,  the  other  will  assume  the  burden,  regardless  of  identity.  If 
the  primary  PSP  fails,  then  the  backup  PSP  should  perform  operations  using  the 
data  received  directly  from  the  avionic  bus,  and  the  interbus  device  may  be 
shut  down,  or  retained  and  fed  with  the  redundant  C&D  data.  The  only 
advantage  of  keeping  the  interbus  device  powered  up  is  in  the  unlikely  event 
that  the  avionic  bus  interface  side  of  the  backup  PSP  failed,  the  avionic  data 
could  be  acquired  from  the  interbus  device. 

Table  8  summarizes  the  advantages  and  disadvantages  of  each  investigated 
topology.  In  each  evaluation,  the  criterion  of  isolation  is  considered  to  be 
an  asset  on  aesthetic  grounds,  while  recognizing  that  isolation  detracts  from 
flexibility  somewhat  by  requiring  that  any  interaction  between  the  avionic 
system  and  the  isolated  PSP(s)  is  required  to  be  essentially  remote. 

Isolation  in  this  case  is  even  more  of  a  detriment  f  r  the  PSPs,  since  they 
are  the  devices  which  will  receive  and  use  the  information.  In  view  of  these 
comments,  along  with  the  observation  that  the  dual  PSP  has  more  advantages  and 
fewer  disadvantages  than  any  other  configuration,  the  recommendation  of  this 
trade  study  is  the  implementation  of  parallel  PSPs  in  the  interbus 
configuration. 

3.  TRADE  STUDY  CONCLUSIONS  AND  RECOMMENDATION 


The  six  devices  listed  below  were  considered  for  performing  the  interbus 
communication  function: 

o  Generator  Control  Unit  (GCU) 
o  Electrical  Load  Management  Center  (ELMC) 
o  DAIS  Remote  Terminal  (RT) 
o  Power  System  Processor  (PSP) 
o  Dedicated  Remote  Terminal 
o  Special  Purpose  Tnterbus  Processor 

An  examination  of  these  devices  resulted  in  the  conclusion  that  the  GCU,  ELMC 
and  the  special  purpose  interbus  processor  were  not  considered  viable 
candidates  for  the  interbus  communication  function,  and  further  evaluation  of 
these  units  was  discontinued.  The  other  three  units  -  the  DAIS  RT,  dedicated 
RT  and  the  PSP  -  were  evaluated  in  adequate  detail  as  summarized  in  Table  8. 
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TABLE  8  EVALUATION  OF  INTF.RBUS  CONFIGURATIONS 


CONFIGURATION 


ADVANTAGES 


DISADVANTAGES 


(a)  DUAL  PROCESSORS 
(BASELINE 


Interbus  data  transfer  is  PSPs  are  not  isolated 
not  required;  from  avionics  bus 

PSPs  provide  backup  control 
to  avionics  bus 
Lowest  bus  loading 
Simplified  operations  on 
failure  of  primary 
interbus  device 
Least  expensive 


(b)  DUAL  RTs 


PSPs  are  isolated  from 
avionics  bus 


Decrea;e  in  topological 
rel  i  abi  1  i  ty 
Most  expensive 
Determination  of 

interbus  device  status 
required  by  backup  PSP 
on  transition 


(c)  BACKUP  PSP  and  RT  Primary  PSP  is  isolated 

from  avionic  bus 

Bus  loading  is  low 
during  backup  PSP 
operations 

Backup  PSP  provides  backup 
control  to  avionics  bus 


Backup  PSP  is  not 

isolated  from  avionic 
bus 

Bus  loading  is  higher 

during  normal  operations 

RT  is  useless  in  backup 
PSP  operation 


(d)  PRIMARY  PSP 
and  RT 


Backup  PSP  is  isolated  from 
avionic  bus 

Bus  loading  is  low  during 
normal  PSP  operations 
Primary  PSP  provides  backup 
control  to  avionics  bus 


Primary  PSP  is  not 

isolated  from  avionic 
bus 

Bus  loading  is  higher 
during  backup  PSP 
operations 


CONCLUSION:  Configuration  (a)  dual  processors  is  recommended. 
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To  meet  the  described  reliability  (3.5  million  hours  MTBF)  at  least  dual 
redundancy  was  necessary.  Three  redundancy  modes  as  listed  below  were 
examined. 

o  Active /Standby  mode  with  "cold"  standby 
o  Acti ve/Standby  mode  with  "hot"  standby 
o  Acti ve /Acti ve  mode 

The  Active/Standby  mode  with  "hot"  standby  was  found  to  be  most  suitable, 
since  it  did  not  impose  any  restrictions  on  the  interbus  configuration. 

investigation  of  four  topological  arrangements  was  also  made  as  follows: 

o  Two  dedicted  RTs 
o  Two  PSPs 

o  One  dedicated  RT  and  the  primary  PSP 
o  One  dedicated  RT  and  the  backup  PSP. 

The  most  suitable  combination  was  the  two-PSP  configuration.  This 
configuration  will  have  the  primary  PSP  act  as  the  primary  interbus  device  and 
continue  to  synopsize  the  avionics  data  in  normal  data  transmissions  to  the 
backup  PSP.  This  configuration  will  aid  in  minimization  of  bus  traffic  on  the 
electrical  system  data  bus. 

Therefore,  it  is  recommended  tSat  the  primary  and  backup  PSPs  be  upgraded  to 
the  MIL-STD-1750A  ISA  processor  configuration  such  that  they  can  perform  the 
interbus  communication  functions.  They  should  be  configu-ed  in  active/"hot" 
standby  mode  and  the  suggested  avionics/electrical  power  system  data  bus 
interfaces  should  be  as  shown  in  Figure  48. 

4.  CONCEPTUAL  DESIGN  OF  A  MULTIBUS  SYSTEM 

In  this  task,  a  conceptual  design  of  an  advanced  aircraft  electrical  system 
incorporating  a  multibus  control  system  was  completed.  In  the  conceptual 
design,  the  electrical  power  subsystem  and  the  distribution  subsystem  remained 
the  same.  The  actual  operation  also  remained  unchanged. 
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AVIONIC 
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Figure  48.  Recommended  Configuration 


a .  Hardware 


The  control  subsystem  was  modified  to  incorporate  the  multibus  architecture 
and  the  PSP  which  can  perform  the  interbus  communication  functions.  The  data 
bus  system  for  the  multibus  erchitecture  is  shown  in  Figure  49. 

The  PSPs  were  upgraded  to  MIL-STD-1750A  from  MIL-STD-1750.  The  1750A  has 
provisions  for  multiple  bus  communications.  As  stated  in  Section  3,  the 
primary  PSP  will  act  as  the  primary  interbus  device.  The  primary  and  backup 
PSPs  (interbus  devices)  are  configured  in  the  active/‘'hot"  standby  mode. 

The  electrical  system  and  the  multibus  architecture  are  shown  in  Figure  50. 

In  addition  to  providing  the  interbus  communication  functions,  the  PSP  picks 
up  the  burden  of  performing  the  bus  control  functions  for  the  electrical 
system  data  bus.  The  controls  and  displays  unit  is  moved  from  the  electrical 
system  control  bus  to  another  bus.  All  controls  and  displays  data  must  now  go 
through  the  avionics  data  bus.  In  the  multibus  configuration,  the  electrical 
system  can  operate  independent  of  the  avionics  system,  unlike  the  integrated 
data  bus  system  which  must  rely  on  the  avionics  system  processor  for  bus 
control . 

b .  Software 

The  multibus  architecture  requires  a  new  executive  for  the  PSP.  The  executive 
is  a  modified  version  of  the  Single  Processor  Synchronous  Executive  (SPSE) 
currently  used  in  DAIS.  The  modification  will  result  in  a  new  executive 
called  the  Multibus  Synchronous  Executive  (MBSE).  The  relation  between  the 
MBSE  and  the  application  software  and  hardware  is  shown  in  Figure  51. 

The  SPSE  and  the  MBSE  are  both  table-driven,  i.e.,  relying  on  values  supplied 
in  tables  to  determine  their  operations.  The  MBSE  functiona'  flow  will  appear 
no  different  than  the  functional  flow  for  the  SPSE,  since  the  primary 
difference  in  the  two  executives,  with  respect  to  multiple  bus  interface,  will 
be  modified  data  base  structure  and  accessing,  while  the  control  logic  remains 
the  same.  Thus,  the  same  code  is  used  to  control  both  busses,  and  the  same 
logic  is  followed,  with  a  variable  indicating  which  bus  is  actually  being 
accessed  by  the  code. 
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49.  AEPS  Multiple  Date  Bu»  Architecture 


Figure  50.  Multibus  Configuration  for  AAES 
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1750A  PROCESSOR 


Figure  51.  Multibus  Processor  Executive 


Likewise,  the  interbus  data  transfer  function,  in  it  simplest  form,  is  a 
matter  of  manipulating  tables.  Each  bus  interface  is  supplied  with  the 
address  of  a  table  of  compool  block  addresses,  indexed  by  bus  subaddress.  The 
bus  interface  units  then  autonomously  access  the  DMA  pointer  tables  during 
normal  operation.  The  interbus  data  transfer  function  is  then  easily 
performed  by  having  the  address  of  a  compool  block  to  be  transferred  present 
in  the  DMA  pointer  tables  during  normal  operatin.  The  interbus  data  transfer 
function  is  then  easily  performed  by  having  the  address  of  a  compool  block  to 
be  transferred  present  in  the  DMA  pointer  table  for  more  than  one  bus 
interface.  Note  that  after  the  bus  interface  begins  operation,  the  executive 
need  only  respond  to  error  and  end-of-operation  conditions,  and  does  not 
concern  itself  with  bus  operations,  including  the  interbus  dat.'.  transfer 
function. 

5.  SIMULATOR  SUPPORT  HARDMARE/SOFTWARE  DESIGN 

Nominal  changes  are  required  in  the  laboratory  simulator  design.  Shown  in 
Figure  52  is  the  laboratory  simulator  configuration  necessary  to  support  the 
multibus  architecture.  The  dashed  lines  represent  changes  in  data  bus 
connection  for  the  multibus  architecture  The  only  equipment  change  is  the 
use  of  a  MIL-STD-1 750A  processor  instead  of  a  MIL-STD-1750.  The  1750A  has 
provisions  for  multiple  1553B  ports.  In  the  multibus  configuration,  the 
avionics  simulator  will  drive  the  controls  and  display  unit  and  will  interface 
the  electrical  system  through  the  additional  1553B  port  on  the  1750A 
processor.  Functionally,  the  avionics  simulator  software  remains  unchanged. 
The  block  diagram  of  the  avionics  simulator  software  is  shown  in  Figure  37. 
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Figure  52.  Laboratory  Simulator  Block  Diagram 


SECTION  VII 


RESULTS  AND  CONCLUSIONS 


The  design  of  the  advanced  aircraft  electrical  system  (AAES)  for  a  two  engine 
tactical  aircraft  and  a  laboratory  demonstrator  was  completed.  The  design  was 
based  on  a  single  data  bus  architecture  on  which  the  avionics  and  e  ectrical 
systems  were  integrated.  To  increase  the  utility  of  the  AAES  design,  the 
program  was  expanded  to  include  the  conceptual  design  of  a  multiple  data  bus 
architecture  system.  The  design  was  the  result  of  a  two  phase  program.  Each 
phase  consisted  of  3  tasks. 

The  first  task  consisted  of  a  requirement  analysis  in  which  the  AAES 
requirements  were  established.  A  load  analysis  was  conducted.  From  this  it 
was  determined  that  the  power  generator  system  consist  of  2  -  60  KVA  115  VAC 
generators,  3-100  Amp  28  VDC  transformer  rectifier  units,  and  1-20  KVA  115  VAC 
auxiliary  generator.  To  ensure  maximum  fault  isolation,  the  generators  and 
transformer  rectifier  units  operate  isolated.  The  number  of  SSPC  required  for 
the  AAES  is  500.  Originally  it  was  determined  that  these  would  be  contained 
in  5  ELMCs;  however,  in  the  detailed  design  phase  it  was  changed  to  7  ELMCs 
because  of  packaging  constraints.  The  AAES  provides  uninterruptible  power  to 
flight  critical  loads  requiring  it.  This  is  accomplished  by  establishing  an 
uninterruptible  bus  in  the  ELMC.  This  bus  is  powered  from  the  normal  DC  bus 
and  from  the  battery  (using  diode  paralleling).  A  study  was  conducted  on  the 
applicability  of  using  J73/I  (JOVIAL)  for  programming  the  power  system 
processors.  The  study  indicated  that  J73/I  is  the  preferred  language  (over 
assembly  language). 

The  requirements  for  the  AAES  control  system  were  defined.  This  included  the 
control  algorithms  and  system  inputs  and  outputs.  The  algorithms  consisted  of 
1500  Boolean  equations  with  1351  inputs  and  1044  outputs.  The  system  response 
time  of  50ms  for  5$  of  the  I/O  and  300ms  for  95%  of  the  I/O  was  defined. 
Processor  and  data  bus  loading  were  analyzed  for  three  different 
architectures.  To  achieve  optimum  bus  loading  and  processor  loading  a 
distributed  processing  network  was  required.  Some  of  the  processing  was  moved 
from  the  central  processor  to  the  ELMCs.  The  three  control  system 
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architectures,  the  non-integrated,  the  integrated,  and  the  hierarchical,  were 
analyzed.  Based  on  the  requirements  analysis,  a  conceptual  design  was 
performed  for  each  of  the  data  bus  architectures. 

In  order  to  examine  the  feasibility  of  integrating  the  power  system  control 
function  into  the  DAIS  architecture,  two  conceptual  designs  were  configured 
which  have  varying  degrees  of  integration  with  the  avionics  data  bus.  In  the 
first  design,  the  integrated  concept,  both  avionics  and  power  system  control 
was  accomplished  using  a  common  data  bus.  In  the  second  design,  the 
hierarchical  concept,  a  separate  data  bus  was  used  for  the  avionics  and  the 
power  system  control .  The  power  system  processor  was  connected  to  both  the 
avionics  and  power  data  buses  and  performed  the  additional  function  of 
interbus  processing. 

The  third  design  was  the  dedicated  or  non-integrated  power  system  control 
concept.  In  this  arrangement  the  avionics  and  power  system  control  functions 
were  totally  separate  with  a  separate  data  bus  for  each.  Such  an  architecture 
probably  could  not  be  justified  for  a  light  tactical  fighter.  However,  this 
concept  was  used  as  a  baseline  for  comparing  the  two  approaches  described  in 
the  previous  paragraph  and  for  determining  power  system  control  requirements 
for  a  light  tactical  aircraft. 

Based  on  an  analysis  of  e'ch  of  the  conceptual  designs,  the  integrated 
avionics  and  power  system  architecture  using  a  single  data  bus  system  was 
selected  for  preliminary  design.  This  system  required  only  minor  changes  to 
the  existing  DAIS  concept.  In  this  configuration  the  power  system  processor 
acted  as  an  RT  and  all  executive  software  would  be  "off-the-shelf".  The 
selection  of  the  integrated  architecture  was  based  on  the  assumption  that 
avionics  bus  loading  including  overhead  would  not  exceed  36%  of  total  capacity 
of  a  MIL-STD-1553B  data  bus. 

A  conceptual  design  of  a  laboratory  simulator  was  conducted.  The  simulator 
was  designed  to  support  both  a  hierarchical  and  an  integrated  architecture. 

The  simulator  will  be  located  in  the  Aero  Propulsion  Laboratory  facilities  and 
will  make  use  of  existing  equipment  wherever  feasible. 


Task  3  of  Phase  I  of  the  Advanced  Aircraft  Electrical  System  Control 
Technology  Demonstrator  Program  consisted  of  preparing  a  preliminary  design  of 
the  electrical  cower  system  with  an  integrated  electrical /avionics  data  bus 
architecture.  Drafts  were  prepared  of  Part  I  specifications  of  the  overall 
system  and  the  major  components,  hardware  and  software.  The  preliminary 
performance  requirements  for  the  power  system  processor,  electrical  load 
management  center,  and  electrical  remote  terminals  were  defined.  The  software 
for  the  PSP  and  £RT  are  divided  into  the  Executive  and  Applications  Software. 
Both  the  PSP  and  ERT  will  use  the  DAIS  Single  Processor  Synchronous  Executive 
(DAIS  Part  I  Specification  SA  221308)  with  minor  modifications  and  will  not 
include  the  bus  control  functions.  In  the  integrated  architecture  design  the 
bus  control  function  will  reside  in  the  Avionics  Processor. 

Outlines  of  the  Part  I  specifications  of  the  System  Test  Console  and  the 
Advanced  Electrical  Power  System  (AEPS)  Simulator  were  also  prepared,  as  was  a 
draft  outline  of  the  Initial  Demonstration  Plan. 

Preliminary  design  studies  for  the  laboratory  simulator  indicated  that  the  bus 
monitor  and  the  avionics  s mtulator/bus  controller  functions  can  be  performed 
by  off-the-shelf  hardware  boxes  at  a  cost  of  approximately  $20K  each.  Two 
such  boxes  would  be  needed.  It  will  be  necessary  to  build  the  ELMC/ERT,  and 
to  provide  a  power  system  processor,  DAIS  RT,  and  a  generator  control  unit  in 
addition  to  a  load  bank  and  operator  console  in  order  to  successfully 
implement  the  laboratory  simulator. 

A  preliminary  hazard  analysis  (PHA)  of  the  system  was  conducted  and  was 
documented  separately.  This  PHA  indicated  that  none  of  the  major  component 
failures  will  be  of  a  catastrophic  or  critical  category,  and  thus  the  program 
can  move  from  the  preliminary  to  detailed  design  phase  without  major 
re orientation. 

All  aspects  of  the  design  indicated  that  the  basic  integrated  architecture  for 
avionics/power  system  control  was  feasible  and  should  continue  into  the  next 
phase.  The  design  philosophy  selected  segregates  the  avionics  data  bus 
traffic  and  power  system  data  bus  traffic  by  utilizing  separate  avionics  and 
power  system  processors  and  allows  considerable  flexibility  by  minimizing,  if 
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not  eliminating,  the  impact  of  changes  in  one  from  the  other.  An  added 
benefit  of  this  design  philosophy  was  the  capability  of  transitioning  the 
design  from  an  integrated  to  a  hierarchical  data  bus  architecture. 

Phase  II  of  the  AAESCTD  consisted  of  three  tasks,  detailed  design  of  the  AAtS, 
detailed  design  of  the  laboratory  simulator  and  an  investigation  of  a  multibus 
architecture.  The  detailed  design  was  based  on  results  of  the  preliminary 
design.  Part  I  development  specifications  were  prepared  for  the  AAES,  for  the 
major  hardware  and  software  components.  These  specifications  specify  the 
performance  requirements.  A  demonstration/test  plan  was  prepared  for  the 
initial  laboratory  checkout  of  the  AAES.  An  operating  and  support  hazard 
analysis  (O&SHA)  was  performed  to  identify  and  eliminate  or  control  hazards 
within  operational  procedures.  From  the  O&SHA,  operational  safety 
requirements  were  established.  A  complete  listing  of  the  specifications  and 
drawings  for  the  AAESCTD  program  is  contained  in  the  appendix. 

In  the  detailed  design  of  the  AAES,  functional  block  diagrams  of  the  system 
were  produced,  these  diagrams  show  data  and  power  flow  between  components. 

This  was  in  addition  to  the  Part  I  specification  which  defined  the  equipment 
(system)  and  the  operation. 

In  the  design,  maximum  use  was  made  of  the  existing  DAIS  hardware.  The  power 
system  processor  and  the  remote  terminals  are  DAIS  hardware.  The  executive 
software  for  the  power  system  processor  and  the  ELMC  are  DAIS  type 
executives.  New  applications  software  will  be  used;  however,  the  software 
design  follows  the  DAIS  structure. 

The  ELMCs,  a  key  component  in  the  AAES,  represent  a  new  design.  A  dual 
processor  architecture  was  used  in  the  ELMC  design  to  increase  reliability  and 
fault  tolerance.  The  ELMC  incorporates  SSPCs  for  control  of  power  to  loads 
and  fault  protection.  The  initial  studies  indicated  a  need  for  an  ELMC  with  a 
capacity  for  100  SSPCs.  Subsequent  design  work  indicated  potential  packaging 
and  thermal  problems.  In  the  final  design,  the  SSPC  capacity  was  lowered  to 
72.  To  keep  a  total  of  500  SSPCs  for  the  system,  the  number  of  ELMCs  was 
increased  from  5  to  7.  An  analysis  was  made  to  determine  the  impact  of  the 
additional  ELMCs  on  the  data  bus  traffic.  The  result  of  this  analysis  showed 


136 


that  the  increase  from  5  to  7  ELMCs  resulted  in  a  3%  increase  in  bus  traffic. 
This  increase  was  acceptable  and  would  have  no  adverse  impact  on  the  system 
performance. 

In  the  detailed  design,  a  dual  redundant  power  system  processor  architecture 
was  incorporated.  The  addition  of  the  backup  processor  resulted  in  a  6% 
increase  in  bus  traffic.  This  increase  is  the  result  of  the  primary  processor 
updating  the  secondary  processor  on  a  periodic  basis. 

To  enhance  the  flexibility  of  the  AAES  design  and  benefit  from  the  design 
development  work  contemplated  in  PAVE  PILLAR'S  Advanced  System  Integration 
Development  (ASID)  Baseline  architecture  development,  an  additional  task, 
multiple  data  bus  architecture  investigations,  was  added  to  Phase  II.  In  this 
task,  the  interbus  processing  requirements  were  defined,  trades  were  conducted 
to  select  the  optimum  unit  to  do  the  interbus  processor  function,  and  a 
conceptual  design  conducted  of  the  AAES  and  its  support  hardware  and  software 
for  the  simulator.  Based  on  the  studies,  the  two  PSPs  will  act  as  the 
interbus  devices.  The  primary  PSP  will  act  as  the  primary  interbus  device  and 
the  secondary  PSP  will  act  as  the  secondary  interbus  device.  They  will  be 
configured  in  an  active/"hot"  standby  mode. 

Based  on  this  interbus  configuration  a  conceptual  design  of  the  AAES  was 
performed.  In  this  design,  the  electrical  power  subsystem  and  the 
distribution  subsystem  remained  the  same.  The  control  subsystem  was  modified 
to  incorporate  the  multibus  architecture  and  the  interbus  PSP.  The  PSPs  were 
upgraded  to  MIL-STD-1750A  from  MIL-STD-1750.  The  1750A  has  provisions  for 
multiple  bus  communications.  The  multibus  architecture  requires  a  new 
executive  for  the  PSP.  The  executive  is  a  modified  version  of  the  Single 
Processor  Synchronous  Executive  (SPSE)  currently  used  in  DAIS.  The 
modification  will  result  in  a  new  executive  called  the  Multibus  Synchronous 
Execrf  ve  (MBSE). 

Nominal  changes  were  made  to  the  laboratory  simulator  design  to  support  the 
multibus  architecture.  The  changes  were  configuration  changes.  The  only 
equipment  change  was  the  use  of  a  MIL-STD-1750A  processor  instead  of  a 
MIL-STD-1750  processor. 


137 


The  results  of  the  AAESCTD  program  show  that  the  AAES  is  feasible  for  an 
advanced  tactical  fighter.  An  assessment  of  the  reliability  of  the  AAES  was 
conducted.  The  results  showed  that  the  system  reliability  will  meet  the 
requirements  for  a  multi-engine,  f!„  by-wire  aircraft  on  a  2.5  hour  mission. 

Two  subcontractors  participated  in  the  AAESCTD  program,  Eaton  Corporation, 
Aerospace  Controls /Systems  Division,  and  Harris  Corporation,  Government 
Information  Systems  Division.  Eaton  Corporation  was  contracted  to  provide  the 
design  for  the  SSPCs.  They  performed  analyses  required  to  determine  the 
optimum  configuration  and  complement  for  the  SSPC  circuit  cards.  This 
resulted  in  specification  sheets  for  AC  and  DC  SSPCs.  Harris  Corporation 
performed  the  design  of  the  ELMC  and  ERT.  Studies  were  performed  which 
addressed  the  thermal,  EMI,  and  reliability  characteristics  of  the  ELMC  and 
ERT,  in  addition  to  the  performance  characteristics.  This  design  effort 
resulted  in  the  Part  I  specifications  for  the  ELMC  and  ERT. 
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SECTION  VIII 


RECOMMENDATIONS 

The  overall  objective  of  this  program  was  to  develop  an  aircraft  electrical 
power  distribution  and  control  system  that  was  integrated  to  the  fullest 
extent  with  an  aircraft  digital  avionics  information  management  system 
(DAIS).  The  requirements  for  such  a  system  were  developed  and  a  design 
prepared  for  the  computer  controlled,  solid  state  electrical  power 
distribution  and  control  system  for  a  small  two  engine  aircraft.  Along  with 
the  aircraft  system  design,  a  laboratory  simulator  design  was  also  completed. 
This  advanced  aircraft  electrical  system  (AAES)  is  a  radical  departure  from 
the  way  electrical  power  is  distributed  and  controlled  in  an  aircraft  today. 
Prior  to  such  a  design  being  implemented  into  the  next  generation  of  aircraft 
it  is  recommended  that  a  comprehensive  simulator  Incorporating  the  features  of 
this  system  be  built.  A  thorough  evaluation  should  be  conducted  to  assure 
that  it  will  meet  the  requirements  of  the  next  generation  aircraft  to  provide 
high  quality,  fault  tolerant  power  for  the  flight  and  mission  critical 
equipment. 

The  critical  development  items  for  achieving  an  AAES  are  as  follows: 

o  PSP  software  -  Executive  and  Application 

-  DAIS  executive  and  application  software  interface 

-  Demonstrate  capabilities  of  software  to  control  AAES  within  the 
framework  of  an  established  operating  system  (DAIS) 

-  Demonstrate  capabilities  of  power  system  software  to  interface  avionics 
system 

o  ERT  Software  -  Executive  and  Application 

-  Adapt  DAIS  executive  to  16-bit  microprocessor 

-  Demonstrate  capabilities  of  software  to  control  and  monitor  SSPCs 

-  Demonstrate  ERT  interface  to  DAIS  operating  system. 

o  ELMC/ERT 

-  Demonstrate  concept  of  distributed  load  centers 

-  Demonstrate  SSPC-ERT  interface 

-  Demonstrate  ERT  software  in  "real"  hardware 
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Both  the  equipment  hardware  and  software  have  to  be  built  and  checked  out 
individually.  Then  these  items  have  to  be  integrated  into  an  overall  system 
simulator. 

To  ensure  that  the  AAES  will  be  available,  in  a  mature  state  for  the  next 
generation  military  aircraft,  it  is  necessary  to  begin  this  development  effort 
now  as  a  logical  follow-on  to  this  program. 
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APPENDIX 

DOCUMENTATION,  DRAWINGS,  SPECIFICATIONS 

As  part  of  the  AAESCTD  contract,  a  series  of  documents,  drawings,  and  Part  I 
development  specifications  were  prepared.  These  items  are  listed  below  along 
with  the  contractor's  report  number. 


Contractor 

Report 

Number 

*D  180-25927  _ TITLE  A  DESCRIPTION _ 

-7  Initial  Demonstration  Plan 

Contains  a  plan  for  the  laboratory  evaluation  of  the  AAES. 

-9  Operating  &  Support  Hazard  Analysis 

Identifies  the  hazards  inherent  in  the  procedures,  the  level  of 
risk  associated  with  each  hazard,  and  the  procedural  (or 
hardware)  features  which  will  be  implemented  to  eliminate  or 
control  the  identified  hazards. 


Simulator  Hardware  Wiring  Diagrams 

Wiring  diagrams  which  show  overall  simulator  hardware  electrical 
wiring. 

Simulator  Hardware  Mechanical  Drawings 

Mechanical  drawings  of  the  AAES  laboratory  uemonstrator . 

Simulator  Block  Diagrams 

Block  diagrams  which  show  the  overall  system  layout  and 
indicates  electrical  power  flow  and  data  flow. 

-101  System  Specification  for  the  Advanced  Aircraft  Electrical 
Control  System 

Establishes  the  system  requirements.  Interfaces,  performance 
characteristics,  and  software  for  the  AAES.  The  document 
describes  the  total  system  operation  and  shows  the  relationship 
between  all  other  component  specifications. 

-102  Electrical  Load  Management  Center  Specification 

Establishes  the  Interfaces,  performance  characteristics,  and  the 
design  and  construction  requirements  for  the  electrical  load 
management  center  (ELMC). 


*  This  number  precedes  the  following  dash  number. 
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APPENDIX  (Continued) 
DOCUMENTATION,  DRAWINGS,  SPECIFICATIONS 


103  Electrical  Remote  Terminal  Specification 

Establishes  the  performance,  design,  and  test  requirements  for 
the  ERT  which  resides  In  the  ELMC. 

104  Solid  State  Power  Controller  Specification 

Specification  sheets  for  AC  and  DC  solid  state  power  controllers. 

105  Power  System  Processor  Specification 

Soecification  for  the  power  system  processor.  The  requirements 
for  the  processor  are  fulfilled  by  the  DAIS  specification  No.  SA 
421205  "Prime  Item  Development  Specification  for  the  AN/AYK-15A 
Digital  Processor." 

106  Bus  Monitor  Specification 

Establishes  the  interfaces,  performance  characteristics  and  the 
design  and  construction  requirements  for  the  bus  monitor. 

107  Avionics  Simulator  Specification 

Establishe>  the  interfaces,  performance  characteristics  and  the 
design  ano  construction  requirements  for  the  avionics 
simulator.  The  avionics  simulator  shall  control  the  1553B  data 
bus  and  simulate  avionics  data  bus  loading. 

108  System  Test  Console  Specification 

Establishes  console  components,  operator  interfaces,  performance 
characteristics,  physical  design  and  construction  requirements 
for  the  system  test  console. 

109  Power  System  Simulator  Specification 

Establishes  performance,  design,  and  interface  requirements  for 
the  AAES  simulator  support  hardware.  Also  establishes  the 
physical  layout  of  all  major  components  and  wiring. 

202A  Electrical  Remote  Terminal  Executive  Software  Specification 

Establishes  the  requirements  for  the  executive  which  provides 
system  software  services  utilized  by  the  ERT  applications 
software . 

202B  Electrical  Remote  Terminal  Application  Software  Specification 

Establishes  the  requirements  for  the  ERT  software  which  controls 
and  monitors  electrical  power  that  is  distributed  to  individual 
aircraft  loads  via  SSPCs. 
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APPENDIX  (Continued) 
DOCUMENTATION,  DRAWINGS,  SPECIFICATIONS 


-205A 


-205B 


-206 


-207 


Power  System  Processor  Executive  Software  Specification 

Establishes  the  requirements  for  the  PSP  executive  which 
provides  system  software  services  utilized  by  the  applications 
software. 

Power  System  Processor  Applications  Software  Specification 

Establishes  the  requirements  for  the  PSP  software  which  manages 
and  controls  the  electrical  power  system. 

Bus  Monitor  Software  Specification 

Establishes  the  requirements  for  the  software  which  monitors  and 
analyses  messages  transmitted  on  the  data  bus. 

Avionics  Simulator  Software  Specification 

Establishes  the  requirements  for  the  software  which  provides  in 
a  laboratory  environment  those  functions  of  the  avionics 
processor  that  are  essential  for  successful  operation  and 
testing  of  the  AAES. 
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